On Fri, Jan 13, 2012 at 5:53 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Andres Freund <andres@anarazel.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.
But on the flip side, I think we're generally a bit more flexible
about exposing things via C than through the procedural languages. I
think it's reasonable for people to complain about their PL/pgsql
functions breaking between major releases, but I have less sympathy
for someone who has the same problem when coding in C. When you
program in C, you're interfacing with the guts of the system, and we
can't improve the system without changing the guts.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
