[PATCHES]JDBC and pg_controldata zh_TW messages

2003-12-03 Thread Zhenbang Wei


pg_controldata-zh_TW.po
Description: Binary data


errors_zh_TW.properties
Description: Binary data

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] introduce "default_use_oids"

2003-12-03 Thread Bruce Momjian
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


Re: [PATCHES] Small documentation patch

2003-12-03 Thread David Fetter
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] Small documentation patch

2003-12-03 Thread Tom Lane
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

2003-12-03 Thread Christopher Kings-Lynne

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

2003-12-03 Thread David Fetter
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;
> > > + Result: 2003-12-03 
> > > 05:54:18
> > >   
> >
> > 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

2003-12-03 Thread Gavin Sherry
On Wed, 3 Dec 2003, Christopher Kings-Lynne wrote:

>
> > + SELECT 'epoch'::timestamp + '1070430858 seconds'::interval;
> > + Result: 2003-12-03 
> > 05:54:18
> >   
>
> 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

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match