Hi,
As a comment to the whole email below, I think the following approach is
the best compromise we will find, allowing everybody to come up with
their own format much as in the Logical Decoding plugins world.
Of course, as in the Logical Decoding area, BDR and similar projects
will implement their own representation, in BDR IIUC the DDL will get
translated into a JSON based AST thing.
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Actually here's another approach I like better: use a new pseudotype,
> pg_ddl_command, which internally is just a pointer to a CollectedCommand
> struct. We cannot give access to the pointer directly in SQL, so much
> like type internal or pg_node_tree the in/out functions should just
> error out. But the type can be returned as a column in
> pg_event_trigger_ddl_command. An extension can create a function that
> receives that type as argument, and return a different representation of
> the command; the third patch creates a function ddl_deparse_to_json()
> which does that.
>
> You can have as many extensions as you want, and your event triggers can
> use the column as many times as necessary. This removes the limitation
> of the previous approach that you could only have a single extension
> providing a CommandDeparse_hook function.
>
> This patch applies cleanly on top of current master. You need to
> install the extension with "CREATE EXTENSION ddl_deparse" after building
> it in contrib.
>
> Note: the extension is NOT to be committed to core, only the first two
> patches; that will give us more room to revisit the JSON representation
> more promptly. My intention is that the extension will be published
> elsewhere.
+1 from me,
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support