Thread: OUTER keyword

OUTER keyword

From
Heikki Linnakangas
Date:
Why is OUTER a type_func_name_keyword? The grammar doesn't require that, 
it could as well be unreserved.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


Re: OUTER keyword

From
Tom Lane
Date:
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Why is OUTER a type_func_name_keyword? The grammar doesn't require that, 
> it could as well be unreserved.

Hm, you sure?  All the JOIN-related keywords used to need to be at least
that to avoid conflicts, IIRC.
        regards, tom lane


Re: OUTER keyword

From
Tom Lane
Date:
I wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Why is OUTER a type_func_name_keyword? The grammar doesn't require that, 
>> it could as well be unreserved.

> Hm, you sure?  All the JOIN-related keywords used to need to be at least
> that to avoid conflicts, IIRC.

Actually, on reflection, it's possible that only JOIN itself really
needs that treatment (because it can be followed by a left paren).
We might have made the JOIN modifier words the same level for
consistency or something.  If we can back off both INNER and OUTER
to unreserved, it might be worth doing.  I'd be a little more worried
about reducing LEFT/RIGHT/FULL, even if it works at the moment.
        regards, tom lane


Re: OUTER keyword

From
Heikki Linnakangas
Date:
On 04.10.2010 18:23, Tom Lane wrote:
> I wrote:
>> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>>> Why is OUTER a type_func_name_keyword? The grammar doesn't require that,
>>> it could as well be unreserved.
>
>> Hm, you sure?  All the JOIN-related keywords used to need to be at least
>> that to avoid conflicts, IIRC.

Yes. OUTER is just an optional noise word in LEFT/RIGHT OUTER JOIN.

> Actually, on reflection, it's possible that only JOIN itself really
> needs that treatment (because it can be followed by a left paren).
> We might have made the JOIN modifier words the same level for
> consistency or something.  If we can back off both INNER and OUTER
> to unreserved, it might be worth doing.  I'd be a little more worried
> about reducing LEFT/RIGHT/FULL, even if it works at the moment.

No, can't change INNER, that creates conflicts.

SELECT * FROM pg_class inner JOIN pg_namespace nsp ON nsp.oid = 
relnamespace;

is ambiguous, "inner" could be either an alias name for pg_class or part 
of "INNER JOIN".

I bumped into the OUTER case because we had a test case in the 
EnterpriseDB test suite using OUTER as a PL/pgSQL variable name. It used 
to work, at least in simple cases where you don't try to use "LEFT OUTER 
JOIN", in 8.4 when PL/pgSQL replaced it with $1 in any SQL statements 
before passing them to the backend. But not anymore in 9.0.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


Re: OUTER keyword

From
Bruce Momjian
Date:
Heikki Linnakangas wrote:
> On 04.10.2010 18:23, Tom Lane wrote:
> > I wrote:
> >> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
> >>> Why is OUTER a type_func_name_keyword? The grammar doesn't require that,
> >>> it could as well be unreserved.
> >
> >> Hm, you sure?  All the JOIN-related keywords used to need to be at least
> >> that to avoid conflicts, IIRC.
> 
> Yes. OUTER is just an optional noise word in LEFT/RIGHT OUTER JOIN.
> 
> > Actually, on reflection, it's possible that only JOIN itself really
> > needs that treatment (because it can be followed by a left paren).
> > We might have made the JOIN modifier words the same level for
> > consistency or something.  If we can back off both INNER and OUTER
> > to unreserved, it might be worth doing.  I'd be a little more worried
> > about reducing LEFT/RIGHT/FULL, even if it works at the moment.
> 
> No, can't change INNER, that creates conflicts.
> 
> SELECT * FROM pg_class inner JOIN pg_namespace nsp ON nsp.oid = 
> relnamespace;
> 
> is ambiguous, "inner" could be either an alias name for pg_class or part 
> of "INNER JOIN".
> 
> I bumped into the OUTER case because we had a test case in the 
> EnterpriseDB test suite using OUTER as a PL/pgSQL variable name. It used 
> to work, at least in simple cases where you don't try to use "LEFT OUTER 
> JOIN", in 8.4 when PL/pgSQL replaced it with $1 in any SQL statements 
> before passing them to the backend. But not anymore in 9.0.

It this a TODO?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


Re: OUTER keyword

From
Heikki Linnakangas
Date:
On 22.02.2011 16:58, Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> On 04.10.2010 18:23, Tom Lane wrote:
>>> I wrote:
>>>> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>   writes:
>>>>> Why is OUTER a type_func_name_keyword? The grammar doesn't require that,
>>>>> it could as well be unreserved.
>>>
>>>> Hm, you sure?  All the JOIN-related keywords used to need to be at least
>>>> that to avoid conflicts, IIRC.
>>
>> Yes. OUTER is just an optional noise word in LEFT/RIGHT OUTER JOIN.
>>
>>> Actually, on reflection, it's possible that only JOIN itself really
>>> needs that treatment (because it can be followed by a left paren).
>>> We might have made the JOIN modifier words the same level for
>>> consistency or something.  If we can back off both INNER and OUTER
>>> to unreserved, it might be worth doing.  I'd be a little more worried
>>> about reducing LEFT/RIGHT/FULL, even if it works at the moment.
>>
>> No, can't change INNER, that creates conflicts.
>>
>> SELECT * FROM pg_class inner JOIN pg_namespace nsp ON nsp.oid =
>> relnamespace;
>>
>> is ambiguous, "inner" could be either an alias name for pg_class or part
>> of "INNER JOIN".
>>
>> I bumped into the OUTER case because we had a test case in the
>> EnterpriseDB test suite using OUTER as a PL/pgSQL variable name. It used
>> to work, at least in simple cases where you don't try to use "LEFT OUTER
>> JOIN", in 8.4 when PL/pgSQL replaced it with $1 in any SQL statements
>> before passing them to the backend. But not anymore in 9.0.
>
> It this a TODO?

If we want to change OUTER, we should just do it now. If not, I don't 
see a TODO here.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


Re: OUTER keyword

From
Tom Lane
Date:
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 22.02.2011 16:58, Bruce Momjian wrote:
>> It this a TODO?

> If we want to change OUTER, we should just do it now. If not, I don't 
> see a TODO here.

I don't see a good reason to change it.  The SQL standard is perfectly
clear that OUTER is a fully reserved word.
        regards, tom lane


Re: OUTER keyword

From
Robert Haas
Date:
On Tue, Feb 22, 2011 at 10:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> On 22.02.2011 16:58, Bruce Momjian wrote:
>>> It this a TODO?
>
>> If we want to change OUTER, we should just do it now. If not, I don't
>> see a TODO here.
>
> I don't see a good reason to change it.  The SQL standard is perfectly
> clear that OUTER is a fully reserved word.

My vote would be to change it.  We don't normally reserve keywords
unnecessarily.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Re: OUTER keyword

From
Tom Lane
Date:
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 22, 2011 at 10:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't see a good reason to change it. �The SQL standard is perfectly
>> clear that OUTER is a fully reserved word.

> My vote would be to change it.  We don't normally reserve keywords
> unnecessarily.

Well, we don't like *upgrading* keywords without real good reason,
but OUTER has had its current classification since forever.  The
argument for trying to downgrade it was to avoid breaking a plpgsql
function that used to work, but I don't have a lot of sympathy for
that.  There are any number of cases where you used to be able
to get away with using reserved words as plpgsql variable names and
now cannot, and most of them are not going to be fixable like this.

The scenario that concerns me is that some future SQL spec addition
uses OUTER in such a way that it has to be reserved again, which
isn't going to bother the committee any since they already think
it's reserved.  Then we have to upgrade it, and all we've accomplished
is to encourage people to write unportable, non-future-proof code.
        regards, tom lane