On Wed, Jan 26, 2011 at 5:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers