Bruce Momjian <[EMAIL PROTECTED]> writes:
> Strangely, CURRENT_TIMESTAMP converts to 'now', not now(). Is that a
> problem?
No, it is not, because the text-to-timestamptz conversion is marked
volatile and won't be const-folded. I've always thought it was a very
ugly implementation though, mainly
Could we cleanly convert 'now' to now()? I assume not because we pass
the string to the date code, and have no way to pass back a function
(now()).
Having now and now() behave differently certainly is strange.
CURRENT_TIMESTAMP works fine, but it does because it isn't in quotes.
Strangely, CUR
On Sun, Jul 27, 2003 at 11:49:10AM -0400, Tom Lane wrote:
> I put up a proposal in pgsql-hackers to change this behavior:
> http://archives.postgresql.org/pgsql-hackers/2003-07/msg00818.php
> If we made that change then the "wrong" way of defining the default
> would fail in an obvious fashion ---
Data entry. You don't necessarily have the option to invoke a function,
as opposed to just sending a string for the datetime input parser.
(It would be rather difficult for an application to allow this one case
without permitting SQL-injection attacks, I'd think.)
Does it mean that the *appli
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> Does it mean that the *application* (not the database) user would then
> have to know the exact specific way to represent the current time in his
> data entry form?
> Such an application looks like (how do I say it politely?) not a very
> user-friendly
Tom Lane wrote:
Dmitry Tkach <[EMAIL PROTECTED]> writes:
Does it mean that the *application* (not the database) user would then
have to know the exact specific way to represent the current time in his
data entry form?
Such an application looks like (how do I say it politely?) not a very
user
Tom Lane wrote:
I put up a proposal in pgsql-hackers to change this behavior:
http://archives.postgresql.org/pgsql-hackers/2003-07/msg00818.php
If we made that change then the "wrong" way of defining the default
would fail in an obvious fashion --- the 'now' would get reduced to a
particular time
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> Why not get rid of 'now' alltogether? Are there any cases when it is
> actually useful as opposed to now()?
Data entry. You don't necessarily have the option to invoke a function,
as opposed to just sending a string for the datetime input parser.
(It wo
On Sun, Jul 27, 2003 at 11:49:10AM -0400, Tom Lane wrote:
>
> I put up a proposal in pgsql-hackers to change this behavior:
> http://archives.postgresql.org/pgsql-hackers/2003-07/msg00818.php
> If we made that change then the "wrong" way of defining the default
> would fail in an obvious fashion -
Denis Zaitsev <[EMAIL PROTECTED]> writes:
> On Sat, Jul 26, 2003 at 10:31:44AM -0400, Tom Lane wrote:
>> That's a dangerous way to define the default --- 'now' is taken as a
>> literal of type timestamp, which means it will be reduced to a timestamp
>> constant as soon as a statement that requires
On Sun, Jul 27, 2003 at 08:47:16AM +0100, Richard Huxton wrote:
>
> No- 'now',now() and CURRENT_TIMESTAMP all stay fixed during a transaction.
> The one that changes is timeofday() I think. See the "Functions and
> Operators" section for details.
Yes, indeed... Documentation describes this. And
> On Sat, Jul 26, 2003 at 03:14:16PM +0100, Richard Huxton wrote:
>> On Saturday 26 July 2003 14:39, Denis Zaitsev wrote:
>
>> Solution: make the default now() or CURRENT_TIMESTAMP and all will be as
>> you
>> expect.
>>
>> PS - I think this is mentioned in the manuals somewhere, but it's not
>> su
On Sat, Jul 26, 2003 at 10:31:44AM -0400, Tom Lane wrote:
> Denis Zaitsev <[EMAIL PROTECTED]> writes:
> > create table xxx (
> > s text,
> > t timestamp
> > default 'now'
> > );
>
> That's a dangerous way to define the default --- 'now' is taken as a
> literal of type timestamp, wh
On Sat, Jul 26, 2003 at 03:14:16PM +0100, Richard Huxton wrote:
> On Saturday 26 July 2003 14:39, Denis Zaitsev wrote:
> > In short, the idea this example is to test for is to split a
> > comma-separated value of some text attribute (given to the INSERT
> > operator) and then insert a row for each
Denis Zaitsev <[EMAIL PROTECTED]> writes:
> create table xxx (
> s text,
> t timestamp
> default 'now'
> );
That's a dangerous way to define the default --- 'now' is taken as a
literal of type timestamp, which means it will be reduced to a timestamp
constant as soon as a statement
On Saturday 26 July 2003 14:39, Denis Zaitsev wrote:
> In short, the idea this example is to test for is to split a
> comma-separated value of some text attribute (given to the INSERT
> operator) and then insert a row for each of the parts of that text
> value. I've tried to do this thru a nested
In short, the idea this example is to test for is to split a
comma-separated value of some text attribute (given to the INSERT
operator) and then insert a row for each of the parts of that text
value. I've tried to do this thru a nested triggers approach.
create
table xxx (
s text,
t tim
17 matches
Mail list logo
