Re: ALTER TYPE 3: add facility to identify further no-work cases
От | Tom Lane |
---|---|
Тема | Re: ALTER TYPE 3: add facility to identify further no-work cases |
Дата | |
Msg-id | 27542.1296081704@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER TYPE 3: add facility to identify further no-work cases (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: ALTER TYPE 3: add facility to identify further no-work cases
Re: ALTER TYPE 3: add facility to identify further no-work cases |
Список | pgsql-hackers |
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.) regards, tom lane
В списке pgsql-hackers по дате отправления: