| 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: | Whole Thread | Raw Message | 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").
| 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 |