Re: Identifying no-op length coercions
От | Robert Haas |
---|---|
Тема | Re: Identifying no-op length coercions |
Дата | |
Msg-id | BANLkTimFcSppy9O3-N=xdDYW6QArqU62pA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Identifying no-op length coercions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Identifying no-op length coercions
|
Список | pgsql-hackers |
On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch <noah@leadboat.com> wrote: >> On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote: >>> On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch <noah@leadboat.com> wrote: >>> > 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 >>> >>> This doesn't quite apply any more. I think the pgindent run broke it slightly. >> >> Hmm, I just get two one-line offsets when applying it to current master. Note >> that you need to run the perl invocation before applying the patch. Could you >> provide full output of your `patch' invocation, along with any reject files? > > Ah, crap. You're right. I didn't follow your directions for how to > apply the patch. Sorry. I think you need to update the comment in simplify_function() to say that we have three strategies, rather than two. I think it would also be appropriate to add a longish comment just before the test that calls protransform, explaining what the charter of that function is and why the mechanism exists. Documentation issues aside, I see very little not to like about this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: