On Wed, Jan 26, 2011 at 5:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Oh, really? I was thinking the logic should go into find_coercion_pathway().
>
> Well, I've been saying right along that it should be in
> eval_const_expressions. Putting this sort of optimization in the parser
> is invariably the wrong thing, because it fails to catch all the
> possibilities. As an example, inlining a SQL function could expose
> opportunities of this type. Another issue is that premature
> optimization in the parser creates headaches if conditions change such
> that a previous optimization is no longer valid --- you may have stored
> rules wherein the optimization was already applied. (Not sure that
> specific issue applies to casting, since we have no ALTER CAST commmand;
> but in general you want expression optimizations applied downstream from
> the rule rewriter not upstream.)
Well, I guess my thought was that we what we were doing is extending
the coercion system to be able to make decisions based on both type
OID and typemod. It seems very odd to make an initial decision based
on type OID in one place and then have a completely different system
for incorporating the typemod; and it also seems quite a bit more
expensive, since you'd have to consider it for every function, not
just casts.
A further problem is that I don't think it'd play well at all with the
richer-typemod concept we keep bandying about. If, for example, we
represented all arrays with the same OID (getting rid of the
double-entries in pg_type) and used some kind of augmented-typemod to
store the number of dimensions and the base type, this would
completely fall over.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company