On Tue, 2008-04-08 at 20:41 -0400, Tom Lane wrote:
> So I'm of the opinion that there's no good reason to change either our
> code or our docs. The standard-incompatibility is with BEGIN, not
> SET TRANSACTION, and it's already documented.
That's a good case. Patch withdrawn.
--
Simon Riggs
Tom wrote:
> So I'm of the opinion that there's no good reason to change either our
> code or our docs. The standard-incompatibility is with BEGIN, not
> SET TRANSACTION, and it's already documented.
Yes.
> PS: the proposed patch is buggy as can be anyway: it applies the
change
> even if !doit,
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I believe the reason the spec is written in the particular way that
> it is is that they wanted to allow, e.g.,
>
> set transaction isolation level serializable;
> set transaction read only;
> sql-command;
> sql-command;
> ...
[ back to this patch ]
Simon Riggs <[EMAIL PROTECTED]> writes:
> The SQL:2003 standard definition of SET TRANSACTION differs in major
> ways from PostgreSQL's, which produces some interesting behaviour.
> We currently claim conformance, though this is not accurate.
I'm still of the opinion that
On Wed, 2008-03-12 at 15:51 -0400, Bruce Momjian wrote:
> Tom's comment on this from the patch queue is that the standard assume
> autocommit off, which affect some of your analysis below.
This isn't an important area for me, but I don't think we follow the
standard in the way we do it now and we
Tom's comment on this from the patch queue is that the standard assume
autocommit off, which affect some of your analysis below.
---
Simon Riggs wrote:
> The SQL:2003 standard definition of SET TRANSACTION differs in major
>
The SQL:2003 standard definition of SET TRANSACTION differs in major
ways from PostgreSQL's, which produces some interesting behaviour.
We currently claim conformance, though this is not accurate.
...
If a that does not specify LOCAL is
executed, then
Case:
i) If an SQL-transaction is curr
