Re: Theory of operation of collation patch

Another interesting item ... I see that you added a collation field to
TypeName, apparently on the grounds that the SQL spec includes collation
in <data type>.  However, it seems to me that that is nonsense up with
which we should not put.  <data type> is basically only used in CAST and
column definitions (plus some features related to methods, which we
haven't got).  In CAST, they have to have a syntax rule stating that you
must not use COLLATE in the target type name.  In column definitions,
they call out <collate clause> as a separate syntactic element, and then
they have to have a syntax rule stating that you can't use both that
and a <collate clause> embedded in the type name.  This is just stupid.
And it conflates the notion of collation with that of type --- based on
our discussions so far, it seems like it'd be a lot better to keep those
separate.

I think we should drop <collate clause> from TypeName and just have it
in columnDef and the expression syntax.  This might also ease the
ambiguity problem that evidently led you to restrict the expression
production's argument to c_expr.  It would also allow us to meet the
letter of the spec for <column definition>, in that <collate clause>
is not required to immediately follow <data type>.  I see that right now
you don't allow <collate clause> in ColQualList, so it's not accepting
syntax that the spec says is valid; and you really can't fix that as long
as <collate clause> can be part of TypeName, because then there would be
two ways to parse the case where COLLATE does immediately follow the
type name.

Thoughts?
        regards, tom lane