Re: [PATCHES] Small documentation patch
On Wed, Dec 03, 2003 at 05:59:25PM +1100, Gavin Sherry wrote: On Wed, 3 Dec 2003, Christopher Kings-Lynne wrote: + SELECT 'epoch'::timestamp + '1070430858 seconds'::interval; + lineannotationResult: /lineannotationcomputeroutput2003-12-03 05:54:18/computeroutput /screen You could also go: SELECT '1070430858'::abstime; But your way is probably a bit more stable...dunno... template1=# SELECT '1070430858'::abstime; ERROR: invalid input syntax for type abstime: 1070430858 I agree its more stable :-). That's on HEAD. Gavin I like more stable. Clearer is good, too :) :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100cell: +1 415 235 3778 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Small documentation patch
template1=# SELECT '1070430858'::abstime; ERROR: invalid input syntax for type abstime: 1070430858 I agree its more stable :-). That's on HEAD. Whoops: SELECT 1070430858::abstime::timestamp; Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Small documentation patch
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Whoops: SELECT 1070430858::abstime::timestamp; Or you can do SELECT '1070430858'::int4::abstime::timestamp; which helps expose the fact that you're really depending on the int4-to-abstime binary equivalence. This will certainly break in 2038... The originally proposed documentation patch is flat wrong: SELECT 'epoch'::timestamp + '1070430858 seconds'::interval; because it will produce a timestamp without time zone, thus effectively making the epoch be 1970-1-1 midnight local time. But of course the correct Unix epoch is 1970-1-1 midnight GMT. So correct code is SELECT 'epoch'::timestamptz + '1070430858 seconds'::interval; or you could use SELECT 'epoch'::timestamptz + 1070430858 * '1 second'::interval; which has the advantage that it works without weird concatenation pushups when the numeric value is coming from a variable. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Small documentation patch
On Wed, Dec 03, 2003 at 10:49:01AM -0500, Tom Lane wrote: SELECT 'epoch'::timestamp + '1070430858 seconds'::interval; because it will produce a timestamp without time zone, thus effectively making the epoch be 1970-1-1 midnight local time. But of course the correct Unix epoch is 1970-1-1 midnight GMT. So correct code is SELECT 'epoch'::timestamptz + '1070430858 seconds'::interval; or you could use SELECT 'epoch'::timestamptz + 1070430858 * '1 second'::interval; which has the advantage that it works without weird concatenation pushups when the numeric value is coming from a variable. Great! I am not attached to any particular way of doing this, just as long as some clue about converting UNIX timestamps into PostgreSQL timestamps gets in there :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100cell: +1 415 235 3778 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] introduce default_use_oids
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Also, I think we have to have a SET before every CREATE TABLE. No, only when the value changes from last time. This is not rocket science, it's the way pg_dump handles SETs already. Yea, that was my point of SET SESSION AUTHORIAZTION --- we already have code to track current user and issue proper set, and somehow restoring individual tables also works in those cases --- let's do the same with oids. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
