Re: New Feature Request
От | Tomas Vondra |
---|---|
Тема | Re: New Feature Request |
Дата | |
Msg-id | 20200526014758.dyezjhp5cqbpfq3c@development обсуждение исходный текст |
Ответ на | Re: New Feature Request (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: New Feature Request
|
Список | pgsql-hackers |
On Mon, May 25, 2020 at 09:21:26PM -0400, Bruce Momjian wrote: >On Mon, May 25, 2020 at 07:53:40PM -0500, Bert Scalzo wrote: >> I am reposting this from a few months back (see below). I am not trying to be a >> pest, just very motivated. I really think this feature has merit, and if not >> generally worthwhile, I'd be willing to pay someone to code it for me as I >> don't have strong enough C skills to modify the PostgreSQL code myself. So >> anyone who might have such skills that would be interested, please contact me: >> bertscalzo2@gmail.com. > >I think your best bet is to try getting someone to write a hook >that will do the replacement so that you don't need to modify too much >of the Postgres core code. You will need to have the hook updated for >new versions of Postgres, which adds to the complexity. > I don't think we have a hook to tweak the incoming SQL, though. We only have post_parse_analyze_hook, i.e. post-parse, at which point we can't just rewrite the SQL directly. So I guess we'd need new hook. I do however wonder if an earlier hook is a good idea at all - matching the SQL directly seems like a rather naive approach that'll break easily due to formatting, upper/lower-case, subqueries, and many other things. From this standpoint it seems actually better to inspect and tweak the parse-analyze result. Not sure how to define the rules easily, though. As for the complexity, I think hooks are fairly low-maintenance in practice, we tend not to modify them very often, and when we do it's usually just adding an argument etc. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: