Vadim Mikheev wrote:
> > I am inclined to think that we should do SetQuerySnapshot in the outer
> > loop of pg_exec_query_string, just before calling
> > pg_analyze_and_rewrite. This would ensure that parse/plan accesses to
>^^
> Actually
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
>
> > I just remembered a report from Forest Wilkinson
> > about a month ago [SQL] SQL functions not locking
> > properly?
>
> Yes, that was on my to-look-at list too. Not sure if it's related.
>
As I replied to his po
> I am inclined to think that we should do SetQuerySnapshot in the outer
> loop of pg_exec_query_string, just before calling
> pg_analyze_and_rewrite. This would ensure that parse/plan accesses to
^^
Actually not - snapshot is passed as param
> > > Snapshot is made per top-level statement and functions/subqueries
> > > use the same snapshot as that of top-level statement.
> >
> > Not so. SetQuerySnapshot is executed per querytree, not per top-level
> > statement --- for example, if a rule generates multiple queries from
> > a user stat
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Is it possible that a rule generates multiple queries from
> a read(select)-only statement ? If so,the queries must
> be executed under the same snapshot in order to guaran
> tee read consistency from user's POV.
> As for non-select queries I'm not sure
> > > Snapshot is made per top-level statement and functions/subqueries
> > > use the same snapshot as that of top-level statement.
> >
> > Not so. SetQuerySnapshot is executed per querytree, not per top-level
> > statement --- for example, if a rule generates multiple queries from
> > a user sta
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Postgres doesn't have an idea of what a 'top-level' statement is? I.E.
> statement as submitted by a client (libpq)?
> >>
> >> There's never been any reason to make such a distinction.
>
> > There's already a distinction.
>
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Postgres doesn't have an idea of what a 'top-level' statement is? I.E.
> statement as submitted by a client (libpq)?
> >>
> >> There's never been any reason to make such a distinction.
>
> > There's already a distinction.
>
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
Postgres doesn't have an idea of what a 'top-level' statement is? I.E.
statement as submitted by a client (libpq)?
>>
>> There's never been any reason to make such a distinction.
> There's already a distinction.
> Snapshot is made per top-level
Tom Lane wrote:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> >> Consider statement boundaries in an SQL function --- the
> >> function is probably being called from some outer statement, so
> >> advancing now() within the function would violate the spec constraint
> >> with respect to the outer
Alex Pilosov <[EMAIL PROTECTED]> writes:
>> Consider statement boundaries in an SQL function --- the
>> function is probably being called from some outer statement, so
>> advancing now() within the function would violate the spec constraint
>> with respect to the outer statement.
> Postgres doesn'
On Wed, 18 Oct 2000, Tom Lane wrote:
> I think what you are advocating is recomputing now() at each statement
> boundary within a transaction, but that's not as simple as it looks
> either. Consider statement boundaries in an SQL function --- the
> function is probably being called from some out
At 12:39 PM 10/18/00 -0400, Tom Lane wrote:
>Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Tom Lane writes:
>>> Au contraire, if it did not behave that way it would violate the spec.
>>> See SQL92 6.8 general rule 3:
>>>
>>> 3) If an SQL-statement generally contains more than one reference
>>>
Tom Lane writes:
> So? It also says that the choice of exactly when to evaluate now()
> is implementation-dependent. Doing so at start of transaction is
> an allowed behavior AFAICS.
But it's only talking about statements. You can't reuse things that you
calculated for previous statements unl
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Au contraire, if it did not behave that way it would violate the spec.
>> See SQL92 6.8 general rule 3:
>>
>> 3) If an SQL-statement generally contains more than one reference
>> to one or more s, then all such ref-
>> erences are
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> That is what now() is defined to return: transaction start time.
>
> > Then CURRENT_TIMESTAMP is in violation of SQL.
>
> Au contraire, if it did not behave that way it would violate the spec.
> See SQL92
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> That is what now() is defined to return: transaction start time.
> Then CURRENT_TIMESTAMP is in violation of SQL.
Au contraire, if it did not behave that way it would violate the spec.
See SQL92 6.8 general rule 3:
3) I
Tom Lane writes:
> That is what now() is defined to return: transaction start time.
> Perhaps the documentation needs improvement...
Then CURRENT_TIMESTAMP is in violation of SQL.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
On Tue, 17 Oct 2000, Alex Pilosov wrote:
> I just ran into a strangest thing: within transaction, select now() will
> always return time when transaction started. Same happens with select
> 'now'::timestamp.
It's feature, not bug. IMHO good feature, an example I use it for rows
identification
"John Huttley" <[EMAIL PROTECTED]> writes:
> Documentation on time constants and how to misuse them is weak...
You can say that again! Who's up for submitting documentation patches?
regards, tom lane
- Original Message -
From: Bruce Momjian <[EMAIL PROTECTED]>
To: Alex Pilosov <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, 18 October 2000 16:21
Subject: Re: [HACKERS] time stops within transaction
> Wow, that is strange.
>
>
> >
Alex Pilosov <[EMAIL PROTECTED]> writes:
> I just ran into a strangest thing: within transaction, select now() will
> always return time when transaction started.
That is what now() is defined to return: transaction start time.
Perhaps the documentation needs improvement...
Wow, that is strange.
> I just ran into a strangest thing: within transaction, select now() will
> always return time when transaction started. Same happens with select
> 'now'::timestamp.
>
> This is with 7.0. I have not tested it with CVS.
>
> I am not sure what causes this. I assume that re
23 matches
Mail list logo
