Re: OUTER keyword
От | Heikki Linnakangas |
---|---|
Тема | Re: OUTER keyword |
Дата | |
Msg-id | 4D63CFC1.4030903@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: OUTER keyword (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: OUTER keyword
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: