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