Dimitri Fontaine 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, CREATE or DROP,
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.
Jim Nasby 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 dump dat
On 10/9/12 2:57 AM, Dimitri Fontaine wrote:
Jim Nasby 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
Robert Haas 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 complex to be struc
On Fri, Oct 12, 2012 at 12:55 PM, Dimitri Fontaine
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
> named by the system a
Dimitri Fontaine 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 attached a demo patch t
Jim Nasby 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 want
> to
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. what'
Tom Lane 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 examples of very invo
Dimitri Fontaine writes:
> Tom Lane 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?
As I said, I be
Tom Lane 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 internally set a
parsetre
On Friday, October 05, 2012 04:24:55 PM Tom Lane wrote:
> Andres Freund 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 eas
Andres Freund 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 ALTER TABLE
> statem
On Friday, October 05, 2012 04:03:03 PM Tom Lane wrote:
> Dimitri Fontaine 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
Dimitri Fontaine 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 mass of maintenance
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
17 matches
Mail list logo
