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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
