Re: [HACKERS] Deparsing DDL command strings

2012-11-04 Thread Dimitri Fontaine
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,

Re: [HACKERS] Deparsing DDL command strings

2012-10-29 Thread Jim Nasby
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-29 Thread Dimitri Fontaine
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-29 Thread Jim Nasby
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.

Re: [HACKERS] Deparsing DDL command strings

2012-10-15 Thread Robert Haas
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-15 Thread Dimitri Fontaine
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-12 Thread Dimitri Fontaine
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-09 Thread Dimitri Fontaine
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-08 Thread Dimitri Fontaine
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-08 Thread Jim Nasby
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.

[HACKERS] Deparsing DDL command strings

2012-10-05 Thread Dimitri Fontaine
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-05 Thread Tom Lane
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-05 Thread Andres Freund
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-05 Thread Tom Lane
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-05 Thread Andres Freund
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?

Re: [HACKERS] Deparsing DDL command strings

2012-10-05 Thread Dimitri Fontaine
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

Re: [HACKERS] Deparsing DDL command strings

2012-10-05 Thread Tom Lane
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