Dimitri Fontaine dimi...@2ndquadrant.fr writes:
The current design for event triggers is to spit out several things:
- command tag is already commited
- object id, can be null
- schema name, can be null
- object name
- operationeither ALTER,
On 10/9/12 2:57 AM, Dimitri Fontaine wrote:
Jim Nasby j...@nasby.net writes:
I definitely want to be able to parse DDL commands to be able to
either enforce things or to drive other parts of the system based on
what's changing. Without the ability to capture (and parse) DDL
commands I'm stuck
Jim Nasby j...@nasby.net writes:
We need to deal with questions like If we rename a table, what do we have
to do in londiste to accommodate that? Except we're dealing with more than
just londiste. We have internal code that does things like track seed
tables, which are tables that we need to
On 10/29/12 4:30 PM, Dimitri Fontaine wrote:
In some cases we may need to divert or reject DDL, but that's a
secondary concern.
Reject is already in, just RAISE ERROR from the trigger code. Divert is
another sell entirely, we currently miss that capability. I'm interested
into it for some DDLs.
On Fri, Oct 12, 2012 at 12:55 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
The user of that command string still has to know what to look for and
maybe should include a proper SQL parser, but at least it doesn't need
to do much guesswork about how the serial attached sequence will get
Robert Haas robertmh...@gmail.com writes:
IMHO, it should be our explicit goal for clients not to need to parse
any SQL at all. I think that the communication between the server and
event triggers should be accomplished using magic variables. If the
+1 on that. There's a but.
data is too
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
I'll show some examples of very involved command (CREATE and ALTER TABLE
are the most complex we have I think) and some very simple commands
(DROP TABLE is one of the simplest), so that we can make up our minds on
that angle.
So please find
Jim Nasby j...@nasby.net writes:
I definitely want to be able to parse DDL commands to be able to
either enforce things or to drive other parts of the system based on
what's changing. Without the ability to capture (and parse) DDL
commands I'm stuck creating wrapper functions around anything I
Tom Lane t...@sss.pgh.pa.us writes:
going to be required below that ... but the point I'm trying to make is
that it would be a one-and-done task. Adding a requirement to be able
to decompile raw parse trees will be a permanent drag on every type of
SQL feature addition.
I'll show some
On 10/5/12 11:15 AM, Tom Lane wrote:
Also, we need to normalize that command string. Tools needing to look at
it won't want to depend on random white spacing and other oddities.
Instead, they'll get to depend on the oddities of parse transformations
(ie, what's done in the raw grammar vs.
Hi,
Working on the Event Trigger next patch series, one of the challenge to
address is deparsing the DDL commands so that the User Defined Function
used by the trigger definition has that information.
I'm making good progress on that, it's some amount of code but pretty
straightforward. The only
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
So I have a Node *parsetree containing some CHECK and DEFAULT raw
expressions to work with. Those can reference non existing tables,
either to-be-created or already-dropped.
Why don't you just pass the original query string, instead of writing
a
On Friday, October 05, 2012 04:03:03 PM Tom Lane wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
So I have a Node *parsetree containing some CHECK and DEFAULT raw
expressions to work with. Those can reference non existing tables,
either to-be-created or already-dropped.
Why don't
Andres Freund and...@2ndquadrant.com writes:
On Friday, October 05, 2012 04:03:03 PM Tom Lane wrote:
Why don't you just pass the original query string, instead of writing
a mass of maintenance-requiring new code to reproduce it?
Its not easy to know which tables are referenced in e.g. an
On Friday, October 05, 2012 04:24:55 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Friday, October 05, 2012 04:03:03 PM Tom Lane wrote:
Why don't you just pass the original query string, instead of writing
a mass of maintenance-requiring new code to reproduce it?
Tom Lane t...@sss.pgh.pa.us writes:
Why don't you just pass the original query string, instead of writing
a mass of maintenance-requiring new code to reproduce it?
Do we have that original query string in all cases, including EXECUTE
like spi calls from any PL? What about commands that
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Why don't you just pass the original query string, instead of writing
a mass of maintenance-requiring new code to reproduce it?
Do we have that original query string in all cases, including EXECUTE
like spi
17 matches
Mail list logo
