Jasen Betts wrote:
On 2012-05-29, David Salisbury salisb...@globe.gov wrote:
On 5/27/12 12:25 AM, Jasen Betts wrote:
The query: show integer_datetimes; should return 'on' which means
timestamps are microsecond precision if it returns 'off' your database
was built with floating point timstamps
On 2012-05-29, David Salisbury salisb...@globe.gov wrote:
On 5/27/12 12:25 AM, Jasen Betts wrote:
The query: show integer_datetimes; should return 'on' which means
timestamps are microsecond precision if it returns 'off' your database
was built with floating point timstamps and equality
On 2012-05-30, David Salisbury salisb...@globe.gov wrote:
On 5/30/12 9:42 AM, Adrian Klaver wrote:
Think I realize where the confusion is now. When Jasen mentioned integer
datetimes he was referring to the internal storage format Postgres uses
to record the datetime value. Via the magic of
On 05/29/2012 07:08 PM, Adrian Klaver wrote:
On 05/29/2012 04:28 PM, David Salisbury wrote:
On 5/27/12 12:25 AM, Jasen Betts wrote:
The query: show integer_datetimes; should return 'on' which means
timestamps are microsecond precision if it returns 'off' your database
was built with floating
On 5/30/12 9:42 AM, Adrian Klaver wrote:
Think I realize where the confusion is now. When Jasen mentioned integer
datetimes he was referring to the internal storage format Postgres uses
to record the datetime value. Via the magic of programming(others will
have to fill that part in) the
On 05/30/2012 01:48 PM, David Salisbury wrote:
On 5/30/12 9:42 AM, Adrian Klaver wrote:
Think I realize where the confusion is now. When Jasen mentioned integer
datetimes he was referring to the internal storage format Postgres uses
to record the datetime value. Via the magic of
On 5/27/12 12:25 AM, Jasen Betts wrote:
The query: show integer_datetimes; should return 'on' which means
timestamps are microsecond precision if it returns 'off' your database
was built with floating point timstamps and equality tests will be
unreliable,
I find that rather interesting. I
On 05/29/2012 04:28 PM, David Salisbury wrote:
On 5/27/12 12:25 AM, Jasen Betts wrote:
The query: show integer_datetimes; should return 'on' which means
timestamps are microsecond precision if it returns 'off' your database
was built with floating point timstamps and equality tests will be
On 2012-05-18, David Salisbury salisb...@globe.gov wrote:
So one question I have is if there a way to set PG in the way Oracle does it..
probably not.
set nls_date_format = '...' so I can query and see exactly what PG is
seeing,
even to the microseconds?
set datestyle to 'ISO';
Is
David Salisbury salisb...@globe.gov writes:
Actually, figured I'd post the whole function, painful as it
might be for anyone to read. If anyone sees something that's a bit
of a risk ( like perhaps the whole thing ;)
Well, I don't know exactly what's causing your issue, but I see a few
things
On 05/18/2012 04:19 PM, David Salisbury wrote:
I'm trying to debug an intermittent problem I'm seeing in one of our
rollup scripts.
I'll try to summarize. A table has a measured_at field, of which I
calculate another
time value based on that field and a longitude value, called solar_noon,
and
On 05/19/2012 10:34 AM, David Salisbury wrote:
CCing the list.
On 5/19/12 8:12 AM, Adrian Klaver wrote:
I hope no one looks further into the problem as the case is closed. It
was a coding
problem and not a time matchup problem. Late Friday afternoons just
aren't my most
shining moments.
I'm trying to debug an intermittent problem I'm seeing in one of our rollup
scripts.
I'll try to summarize. A table has a measured_at field, of which I calculate
another
time value based on that field and a longitude value, called solar_noon, and I
summarize
min/max values grouped around
Actually, figured I'd post the whole function, painful as it
might be for anyone to read. If anyone sees something that's a bit
of a risk ( like perhaps the whole thing ;)
On 5/18/12 5:19 PM, David Salisbury wrote:
I'm trying to debug an intermittent problem I'm seeing in one of our
rollup
Oh.. and while I'm polluting this list (sorry) it's a timestamp field
without a time zone.
thanks for any ideas,
-Dave
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
15 matches
Mail list logo
