Re: Identifying no-op length coercions
От | Noah Misch |
---|---|
Тема | Re: Identifying no-op length coercions |
Дата | |
Msg-id | 20110611211304.GB21098@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Identifying no-op length coercions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Identifying no-op length coercions
|
Список | pgsql-hackers |
On Sat, Jun 11, 2011 at 03:03:18PM -0400, Tom Lane wrote: > Noah Misch <noah@leadboat.com> writes: > > Good points. I'm thinking, then, add an Expr argument to simplify_function() > > and have the CoerceViaIO branch of eval_const_expressions_mutator() pass NULL > > for both its simplify_function() calls. If simplify_function() gets a NULL Expr > > for a function that has a protransform, synthesize a FuncExpr based on its other > > arguments before calling the transform function. Seem reasonable? Granted, > > that would be dead code until someone applies a transform function to a type I/O > > function, which could easily never happen. Perhaps just ignore the transform > > function when we started with a CoerceViaIO node? > > Until we actually have a use-case for simplifying I/O functions like this, > I can't see going out of our way for it ... Sounds good. Updated patch attached, incorporating your ideas. Before applying it, run this command to update the uninvolved pg_proc.h DATA entries: perl -pi -e 's/PGUID(\s+\d+){4}/$& 0/' src/include/catalog/pg_proc.h Thanks, nm
Вложения
В списке pgsql-hackers по дате отправления: