Re: SET TRANSACTION and SQL Standard

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SET TRANSACTION and SQL Standard
Date: 2009-01-09 14:39:49
Message-ID: 22728.1231511989@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Simon Riggs wrote:
>> I notice that we allow commands such as
>> SET TRANSACTION read only read write read only;
>> BEGIN TRANSACTION read only read only read only;

> Well, we allow a lot of things. Violations of the SQL standard happen
> when a command that appears in the standard doesn't do what the standard
> says. Allowing commands that are not in the standard is not a violation.

I agree that "spec violation" is not a good argument for rejecting
these. However, self-consistency with our own common practice should
be considered. In practically every utility command we have that takes
a list of options, we throw "conflicting or redundant options" errors
in similar cases.

My own feeling is that the second example is okay but the first should
be rejected, since (a) it's quite unclear what the user wants, and (b)
the ensuing behavior would be determined by implementation artifacts
like which order we processed the options in.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-01-09 14:45:36 Re: SET TRANSACTION and SQL Standard
Previous Message Andrew Dunstan 2009-01-09 14:34:14 parallel restore