| From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, 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-10 21:11:57 |
| Message-ID: | m2obubxnxe.fsf@2ndQuadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Maybe we should try to split the baby here and defer the question of
> whether to expose any of the parse tree internals, and if so how much,
> to a future release. It seems to me that we could design a fairly
> useful set of functionality around AFTER-CREATE, BEFORE-DROP, and
> maybe even AFTER-ALTER triggers without exposing any parse tree
> details.
+1
Also remember that you have a “normalized” command string to play with.
Lots of use cases are already ok here. The other ones would need a tree
representation that's easy to consume, which in the current state of
affairs (I saw no progress on the JSON data type and facilities) is very
hard to imagine when you consider PLpgSQL.
So unless I hear about a show stopper, I'm going to work some more on
the command trigger patch where I still had some rough edges to polish.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2012-01-10 21:43:44 | [WIP] Double-write with Fast Checksums |
| Previous Message | Oleg Bartunov | 2012-01-10 20:43:25 | Re: pgsphere |