Re: Per-column collation, work in progress

On tor, 2010-10-14 at 22:54 -0400, Robert Haas wrote:
> and maybe not that bad, but I wonder if there is some preparatory
> refactoring that could be done to trim it down a bit.  I notice, for
> example, that a lot of places that looked at <asc/desc, nulls
> first/last> now look at <asc/desc, nulls first/last, collation>.  In
> particular, all the pathkey stuff is like this.  And similarly places
> that used to care about <type, typmod> now have to care about <type,
> tymod, collation>.  There might be ways to restructure some of this
> code so that these things can be changed without having to touch quite
> so many places.

Yeah, I think that's what I'll try to do next.

We already have TypeName as a structure that contains type and typmod
(and collation, in my patch).  We could make that a primnode instead of
a parsenode, and use it in more places, or we could make a new leaner
structure that only contains the numeric info.

We could then, for example, change things like this:

typedef struct Var
{   Expr        xpr;   ...   Oid         vartype;   int32       vartypmod;   ...
}

into this

typedef struct Var
{   Expr        xpr;   ...   TypeName/TypeFoo vartype;   ...
}

This would save boatloads of duplicate code.

> It looks like you've define collations as objects that exist within
> particular namespaces, but there's no CREATE COLLATION statement, so I
> don't see what purpose this serves.  I suppose we could leave that to
> be added later, but is there actually a use case for having collations
> in individual schemas, or should we treat them more like we do casts -
> i.e. as database-global objects?

The SQL standard defines it that way, and there should be a CREATE
COLLATION statement later.  Application-specific collation sequences
might not be unreasonable in the future.

> Why does the executor ever need to see collate clauses?

Hmm, maybe not.  I think it did in an earlier working draft.