Re: [HACKERS] column labels now with obligatory 'as'

> The as keyword is now obligatory as in:
>
> regression=> select name a, age b from emp;
> ERROR:  parser: parse error at or near "a"

I have confirmed that this has been the behavior since at least v6.0. It
does appear to be the case that omitting the "AS" is allowed in SQL92
syntax. As you note below, conflicts in syntax with unary operators are
the problem. I suspect it is the right unary operators only, of which
there are only a few:

  ! integer factorial
  % truncate float8

The unary right operators have another problem:

postgres=> select 1.23 %;
ERROR:  parser: parse error at or near ""

For some reason the parser can't end a statement with a unary right
operator. Don't know why exactly. Can currently work around by adding junk
to the end or by putting parens around:

postgres=> select 1.23 % order by 1;
?column?
--------
       1
(1 row)

> strange results as in (should be syntax error):
> regression=> select name 'a' from emp;
> ?column?
> --------
> a
> (1 row)

This is new support for SQL92 type specification of string constants.  The
syntax requires a valid type followed by a string literal constant. "name"
is a Postgres type. Glad it works :)

> Since the other(DBMS)s don't insist on the as I would suggest not to be
> stricter than the others even if it needs a lot of brainwork. (Tom ?)

Do other systems allow right unary operators? Which ones now allow
creating new right unary operators? How do they handle it? These are the
features which lead to the parser ambiguities, since you can't hardcode
the cases into yacc, our parser-of-choice.

> Might try something like:
>         if not registered right unary operator then label (probably no
> good)

yacc would still have already found shift/reduce conflicts...

> or
>         force non alpha 1. char for unary operators (i think this is
> best)

This isn't the source of the problem, and in fact is already required by
the scanner. The problem is with parsing

  column Op label
vs
  column Op column

> or even
>         disallow creation of right and left unary operators alltogether
> (can always use function instead)

Well, losing other features to get this one may not be worth it- "throwing
out the baby with the bathwater".

> hm... really not easy...
> Comments ?

The problem is with parsing

  column Op label
vs
  column Op columnThe parser only knows about syntax, and is not allowed
to peek and see if, for example, something is a valid type (at that point
yacc has already complained anyway).

We could probably break the shift/reduce conflict in yacc by insisting
that right unary expressions be enclosed in parentheses, but that seems
ugly. It is certainly true though that the most common action by users is
labeling columns, not using right unary operators. Comments?

                                                       - Tom

Another lurking problem is allowing ";" to be an operator as well as a
statement terminator. Probably a holdover from Postquel, but doesn't work
at all well in SQL. We should yank it.