am Fri, dem 20.06.2008, um 8:35:10 +0200 mailte Peter Kovacs folgendes:
> Thank you, Andreas! Your advice is very useful to me.
>
> I would still be interested why "TZ" is not accepted in the format string.
I think because TZ is only useful for displaying a timestamptz and not
for internal repr
Thank you, Andreas! Your advice is very useful to me.
I would still be interested why "TZ" is not accepted in the format string.
Thanks
Peter
On Fri, Jun 20, 2008 at 8:15 AM, A. Kretschmer
<[EMAIL PROTECTED]> wrote:
> am Fri, dem 20.06.2008, um 7:51:50 +0200 mailte Peter Kovacs folgendes:
>>
am Fri, dem 20.06.2008, um 7:51:50 +0200 mailte Peter Kovacs folgendes:
> Hi,
>
> Execution of the following statement aborts with the error message in
> the Subject:
>
> select to_timestamp('2008-06-20 02:30:00 GMT', '-MM-DD HH24:MI:SS TZ');
You can use:
test=*# select '2008-06-20 02:30:
Hi,
Execution of the following statement aborts with the error message in
the Subject:
select to_timestamp('2008-06-20 02:30:00 GMT', '-MM-DD HH24:MI:SS TZ');
Does this message mean that this particular PostgreSQL installation
doesn't support timezones?
--
select * from pg_catal
"Fernando Hevia" <[EMAIL PROTECTED]> writes:
> -- In this case function test is called only once:
> pg=# select res[0] as sum, res[1] as prod, res[2] as dif from
> pg-# (select (test(1, 2))::integer[] as res) t ;
That's an implementation artifact, not a guaranteed behavior;
if you change the examp
> > -Mensaje original-
> > De: Scott Marlowe [mailto:[EMAIL PROTECTED] Enviado el:
> > MiƩrcoles, 18 de Junio de 2008 17:47
> > Para: Fernando Hevia
>
> > >
> > > For complex calculations I have obtained better performance using
> > > nested queries. For example:
> > >
> > > select a,
> -Mensaje original-
> De: Scott Marlowe [mailto:[EMAIL PROTECTED]
> Enviado el: MiƩrcoles, 18 de Junio de 2008 17:47
> Para: Fernando Hevia
> >
> > For complex calculations I have obtained better performance using
> > nested queries. For example:
> >
> > select a, b, c select
> > ( s