Re: SESSION SESSION - bug or intentional?
| От | David G. Johnston |
|---|---|
| Тема | Re: SESSION SESSION - bug or intentional? |
| Дата | |
| Msg-id | CAKFQuwZALLTuwXg23Pd34vvcd+4o7f6MWPAFt+zfMbUnHwAVtg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SESSION SESSION - bug or intentional? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wed, Sep 30, 2015 at 2:52 PM, Joe Conway <mail@joeconway.com> wrote:
>> I was looking at something in gram.y when I noticed that the following
>> production works:
>> SET SESSION SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;
>> "SESSION SESSION" seems fairly odd -- is it intentional?
> However, SET SESSION AUTHORIZATION is defined as thus:
> SET [ SESSION | LOCAL ] SESSION AUTHORIZATION user_name
Yeah. SET LOCAL SESSION AUTHORIZATION is valid and useful. The optional
SESSION is just a noise word here, but disallowing it would be
non-orthogonal compared to other similar syntaxes.
While I get the gist of what you are saying the phrase:
"[...] but disallowing it would be non-orthogonal compared to other similar syntaxes."
doesn't compute for me. You mind trying that again?
I take it that means that disallowing it would be "inconsistent" given what we allow in similar commands.
Given that conclusion shouldn't the following be modified?
SET [ SESSION | LOCAL ] SESSION CHARACTERISTICS AS TRANSACTION transaction_mode [, ...]
Both are allowed though the one is redundant and the other (presumably) ignored, repsectively.
A code comment in the grammar would be warranted at the least - not going there myself.
I haven't tried to figure out what exactly LOCAL results in if specified vis-a-vis the presence of absence of an active transcation.
David J.
В списке pgsql-hackers по дате отправления: