Re: OUTER keyword - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: OUTER keyword
Date
Msg-id 4CAADC9A.4060108@enterprisedb.com
Whole thread Raw
In response to Re: OUTER keyword  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: OUTER keyword
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: ALTER DATABASE RENAME with HS/SR
Next
From: Simon Riggs
Date:
Subject: Re: ALTER DATABASE RENAME with HS/SR