Re: type info refactoring

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Here's a big patch to avoid passing around type OID + typmod (+
> collation) separately all over the place. Instead, there is a new
> struct TypeInfo that contains these fields, and only a pointer is passed
> around.

> Some stuff in here (or not in here) is probably a matter of taste, as
> with any such large refactoring, but in general you can see that it
> saves a lot of notational overhead.

I can't escape the feeling that the principal result of this patch will
be a huge increase in palloc overhead. It's certainly going to double
the number of nodes needed for common structures like Vars, Consts,
OpExprs, and FuncExprs. Have you checked the effects on
parsing/planning runtime?

To my mind, the reason we have a distinction between type OID and typmod
is that for most operations, you know the type OID of the result but
not the typmod. Trying to force typmod into every API that currently
works with type OIDs isn't going to alter that, so the net result will
just be a lot of inefficiency and extra notation to carry around
"I don't know" markers.

I'm not entirely sure where collation fits in this worldview, but I
think it is more nearly like typmod than type OID.

I wonder whether it wouldn't work better to keep type OID as it is,
and invent a separate struct that can carry type auxiliary information
(ie, typmod and collation, at present). For the common case where you
don't have any auxiliary information, you just pass a NULL.

Also, maybe I missed this, but do we have a clear understanding of
how collation markers propagate through operations? I seem to remember
that way back when, we were thinking of it as a runtime-determined
property --- for which, managing it like typmod would be quite useless.
This whole approach seems to depend on the assumption that collation
markers can be set at parse time, which isn't something I'm sure works.

regards, tom lane