Re: [GENERAL] PSQLRestore

2011-09-09 Thread Raymond O'Donnell
On 09/09/2011 01:25, Bob Pawley wrote: > > > -Original Message- >> From: Raymond O'Donnell > Sent: Thursday, September 08, 2011 3:23 PM To: Bob Pawley Cc: Adrian > Klaver ; Postgresql Subject: Re: [GENERAL] PSQLRestore > On 08/09/2011 23:02, Bob Pawley wrote: >> The problem seems to be i

[GENERAL] integer instead of 'double precision'?

2011-09-09 Thread Henry Drexler
take any table and run Query - select 1/3 from storage limit 1 Result - ?column? integer 0 Expected Result - ?column? double precision 0.3... Question - Since there is no column type to begin with as this is

Re: [GENERAL] integer instead of 'double precision'?

2011-09-09 Thread Guillaume Lelarge
On Fri, 2011-09-09 at 10:42 -0400, Henry Drexler wrote: > take any table and run > > Query > - > select > 1/3 > from > storage > limit 1 > > > Result > - > ?column? > integer > 0 > > > Expected Result > - > ?column? > double precision

Re: [GENERAL] integer instead of 'double precision'?

2011-09-09 Thread Tom Lane
Henry Drexler writes: > [ "1/3" yields zero ] Yeah, it's an integer division. > I thought perhaps I could cast it as double precision as noted on > http://www.postgresql.org/docs/8.3/interactive/sql-expressions.html > though doing the following: > float8(1/3) That's casting the result of the di

[GENERAL] PostgreSQL Upgrade Procedure

2011-09-09 Thread Carlos Mennens
I've had PG 9.0 installed and working fine however it's Friday and I'm running updates on the server & see that 9.1 is available. I know when I upgrade, I will now have two instances of PostgreSQL installed under /etc/postgresql: Code: slave:~# cd /etc/postgresql slave:/etc/postgresql# ls -l tota

[GENERAL] hiring PostgresSQL admin

2011-09-09 Thread Claire Chang
Merchantcircle.com (acquired by Reply!) is hiring. Please send your resume to me. Thanks, Claire

Re: [GENERAL] hiring PostgresSQL admin

2011-09-09 Thread Merlin Moncure
On Fri, Sep 9, 2011 at 10:47 AM, Claire Chang wrote: > Merchantcircle.com (acquired by Reply!) is hiring. Please send your resume > to me. > Thanks, > Claire Make sure to post your request to the postgresql-jobs list if you haven't already -- that's the preferred place for postgresql job posting

Re: [GENERAL] PostgreSQL Upgrade Procedure

2011-09-09 Thread Raymond O'Donnell
On 09/09/2011 16:35, Carlos Mennens wrote: > I've had PG 9.0 installed and working fine however it's Friday and I'm > running updates on the server & see that 9.1 is available. I know when > I upgrade, I will now have two instances of PostgreSQL installed under > /etc/postgresql: > > Code: > > sl

Re: [GENERAL] integer instead of 'double precision'?

2011-09-09 Thread Henry Drexler
thanks Tom and Guillaume, *That sequencing of casting makes sense - I appreciate the clear explanation. * * * On Fri, Sep 9, 2011 at 11:12 AM, Tom Lane wrote: > Henry Drexler writes: > > [ "1/3" yields zero ] > > Yeah, it's an integer division. > > > I thought perhaps I could cast it as double p

Re: [GENERAL] integer instead of 'double precision'?

2011-09-09 Thread Henry Drexler
Perfect, thank you. I will try to find that in the documentation as I was obviously not looking at the correct page I had linked to earlier. On Fri, Sep 9, 2011 at 11:05 AM, Day, David wrote: > Henry, > > ** ** > > Does this suit your need? > > ** ** > > select 1/3::float as answer;

Re: [GENERAL] integer instead of 'double precision'?

2011-09-09 Thread Scott Ribe
On Sep 9, 2011, at 8:42 AM, Henry Drexler wrote: > any ideas on how to get this type of a manufactured column (not sure the > right term for it) to show the double precision result? Use floating point types in the calculation to begin with. 1.0/3.0 1::float8 / 3::float8 float8(1) / float8(3) 1.

Re: [GENERAL] PostgreSQL Upgrade Procedure

2011-09-09 Thread Steve Crawford
On 09/09/2011 08:35 AM, Carlos Mennens wrote: I've had PG 9.0 installed and working fine however it's Friday and I'm running updates on the server& see that 9.1 is available First!!! Although certain packages like Martin Pitt's PPA for Ubuntu will show PostgreSQL 9.1 as available this is

Re: [GENERAL] Problem with 8.3.14 Windows binaries

2011-09-09 Thread Pete Wall
As an update, we found a 2008 box that had the same problem as below, so it doesn't seem to be a problem with Windows 2003. From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Pete Wall Sent: Wednesday, August 24, 2011 2:54 PM To: pgsql-general@postg

Re: [GENERAL] hiring PostgresSQL admin

2011-09-09 Thread Scott Marlowe
On Fri, Sep 9, 2011 at 9:47 AM, Claire Chang wrote: > Merchantcircle.com (acquired by Reply!) is hiring. Please send your resume > to me. I'm interested, but there's just not enough info here to know what to expect. I'm currently a full time linux sysadmin / pg dba making $90k living in Denver.

Re: [GENERAL] hiring PostgresSQL admin

2011-09-09 Thread Scott Marlowe
Sorry that was just supposed to go to Claire. apologies -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] PG producing odd results on epoch timestamp to string conversion

2011-09-09 Thread Preston Landers
Hi folks, I've got a web app which runs on three databases: PostgreSQL, Oracle and Microsoft SQL Server. This app has columns which contain Unix epoch timestamps generated from Python's time.time() function. Now I need to write DB functions or expressions which convert these timestamps into human

Re: [GENERAL] PG producing odd results on epoch timestamp to string conversion

2011-09-09 Thread Tom Lane
Preston Landers writes: > SELECT TO_CHAR( TIMESTAMP WITH TIME ZONE 'epoch' + 1315503340 * > INTERVAL '1 second', 'MM-DD- HH:MM:SS TZ'); > 09-08-2011 12:09:40 CDT > As you can see, Python, SQL Server, and Oracle all agree that the > timestamp 1315503340 means 12:35:40 CDT on that date. So doe

Re: [GENERAL] PG producing odd results on epoch timestamp to string conversion

2011-09-09 Thread Preston Landers
On Fri, Sep 9, 2011 at 5:13 PM, Tom Lane wrote: >> Yet PostgreSQL >> shows a value that is exactly 26 minutes behind the others (12:09:40). > > You've fat-fingered the to_char usage --- MM is month, not minutes > (I think you want MI for that). > Yep, that's exactly it. Thanks so much for your h