Re: (Fwd) Re: Any Oracle 9 users? A test please...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Mike Mascari <mascarm(at)mascari(dot)com>, Dan Langille <dan(at)langille(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: (Fwd) Re: Any Oracle 9 users? A test please...
Date: 2002-09-30 22:40:28
Message-ID: 12303.1033425628@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I don't see how we can be compliant if SQL92 says:
> The time of evaluation of the <datetime value function> during the
> execution of the SQL-statement is implementation-dependent.
> It says it has to be "during the SQL statement", or is SQL statement
> also ambiguous? Is that why Oracle did what they did?

Yes, you're finally seeing my issue: "SQL statement" isn't all that
well-defined a concept.

ISTM that the reported behavior of Oracle's pl/sql is *clearly* in
violation of SQL92: the body of a pl/sql function is a single <SQL
procedure statement> per SQL92 4.17, so how can they allow
current_timestamp to change within it?

It would be even more interesting to try the same function called
from another pl/sql function --- in that scenario, hardly anyone
could deny that the whole execution of the inner function is contained
within one statement of the outer function, and therefore
current_timestamp should not be changing within it.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-09-30 22:49:34 Re: Postgresql likes Tuesday...
Previous Message Tom Lane 2002-09-30 22:31:15 Re: Postgresql likes Tuesday...