Re: SET TRANSACTION and SQL Standard

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-12 15:07:34
Message-ID: 496B5CB6.2050704@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> 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;

> 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.

I think this might be best solved by providing a common function that
checks a DefElem list for duplicates. This could be used in a number of
other places as well (grep for "conflicting or redundant options").

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-01-12 15:13:06 Re: SET TRANSACTION and SQL Standard
Previous Message Tom Lane 2009-01-12 14:55:14 Re: Recovery Test Framework