Thread: OUTER keyword
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
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
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
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
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. +
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
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
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
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