Thread: SESSION SESSION - bug or intentional?
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? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
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?
Scanning the SET and SET TRANSACTION it doesn't appear to be something they are documented as allowing.
However, SET SESSION AUTHORIZATION is defined as thus:
SET [ SESSION | LOCAL ] SESSION AUTHORIZATION user_namewhich implies that we don't take pains to avoid it. Since:
"The SESSION and LOCAL modifiers are a PostgreSQL extension, as is the RESET syntax."
The standard doesn't have any undue influence on our particular decision.
David J.
"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.
regards, tom lane
"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.