| From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Greg Smith <greg(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Subject: | Re: Command Triggers |
| Date: | 2012-01-13 22:53:32 |
| Message-ID: | m2lipbrz83.fsf@2ndQuadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> I personally think this is an error and those details should at least be
> available on the c level (e.g. some pg_command_trigger_get_plan() function,
> only available via C) to allow sensible playing around with that knowledge. I
> don't really see making progress towards a nice interface unless we get
> something to play around with out there.
If you target C coded triggers then all you need to do is provide a
pointer to the Node *parsetree, I would think. What else?
The drawback though is still the same, the day you do that you've
proposed a public API and changing the parsetree stops being internal
refactoring. The way around this problem is that if you want a command
trigger in C, just write an extension that implements the Process
Utility hook. Bonus, you can have that working with already released
versions of PostgreSQL.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2012-01-13 23:07:02 | Re: Review of: explain / allow collecting row counts without timing info |
| Previous Message | Dimitri Fontaine | 2012-01-13 22:47:51 | Re: Multithread Query Planner |