Re: WIP: Upper planner pathification
| От | Jim Nasby |
|---|---|
| Тема | Re: WIP: Upper planner pathification |
| Дата | |
| Msg-id | 56F2BE6B.30304@BlueTreble.com обсуждение исходный текст |
| Ответ на | Re: WIP: Upper planner pathification (Michael Paquier <michael.paquier@gmail.com>) |
| Список | pgsql-hackers |
On 3/22/16 7:28 AM, Michael Paquier wrote: > On Mon, Mar 21, 2016 at 7:55 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> On 3/17/16 9:01 AM, Robert Haas wrote: >>> >>> I think that >>> there are an awful lot of cases where extension authors haven't been >>> able to quite do what they want to do without core changes because >>> they couldn't get control in quite the right place; or they could do >>> it but they had to cut-and-paste a lot of code. >> >> FWIW, I've certainly run into this at least once, maybe twice. The case I >> can think of offhand is doing function resolution with variant. I don't >> remember the details anymore, but my recollection is that to get what I >> needed I would have needed to copy huge swaths of the rewrite code. > > Amen, I have been doing that a couple of days ago with some elog stuff. Any ideas on ways to address this? Adding more hooks in random places every time we stumble across something doesn't seem like a good method. One thing I've wondered about is making it easier to find specific constructs in a parsed query so that you can make specific modifications. I recall looking at that once and finding a roadblock (maybe a bunch of functions were static?) -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: