Re: timestamp/function question - Mailing list pgsql-general

From Soma Interesting
Subject Re: timestamp/function question
Date
Msg-id 5.0.2.1.0.20010328233707.028f3008@pop.telus.net
Whole thread Raw
In response to Re: timestamp/function question  (will trillich <will@serensoft.com>)
Responses Re: timestamp/function question  (will trillich <will@serensoft.com>)
List pgsql-general
At 12:41 AM 3/29/2001 -0600, you wrote:
>do. In the case of logfunc1(), the Postgres main parser knows
>when preparing the plan for the INSERT, that the string 'now'
>should be interpreted as datetime because the target field of
>logtable is of that type. Thus, it will make a constant from it
>at this time and this constant value is then used in all
>invocations of logfunc1() during the lifetime of the backend.
>Needless to say that this isn't what the programmer wanted.
>
>In the case of logfunc2(), the Postgres main parser does not know
>what type 'now' should become and therefor it returns a datatype
>of text containing the string 'now'. During the assignment to the
>local variable curtime, the PL/pgSQL interpreter casts this
>string to the datetime type by calling the text_out() and
>datetime_in() functions for the conversion.


blah blah blah <snip>

...and that all meant what? The postgres manual is open to much
interpretation to anyone new trying to understand its contents. Combine
that with documentation that's still not written, or broken across several
different sections (programmer, user, admin, etc) and a search engine which
returns absolute crap.... well I guess us new users can just go use MySQL.

as far as I can tell the above sounds like a complicated  work-around to a
bug, but maybe you'll be kind enough to correct me on this...?


pgsql-general by date:

Previous
From: Alexey Borzov
Date:
Subject: Pgsql-7.1RC1: SET SEED =
Next
From: Soma Interesting
Date:
Subject: Fwd: Re: timestamp/function question