Re: review: Deparsing DDL command strings

Hi,

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> ** missing doc

I still would prefer to have an ack about the premises of this patch
before spending time on writing docs for it, namely:

- we want a normalized command string (schema, auto naming of some
objects such as constraints and indexes, exporting default values,
etc);

- this normalisation can not happen as an extension given the current
source code organisation and the new ddl_rewrite module is a good fit
to solve that problem;

- we offer a new event alias "ddl_command_trace" that will get
activated start of a DROP and end of an ALTER or a CREATE command so
that it's easy to hook at the right place when you want to trace
things;

- it's now possible and easy to process GENERATED commands if you wish
to do so (explicit sequence and index operations for a create table
containing a serial primary key column).

I think no complaints is encouraging though, so I will probably begin
the docs effort soonish.

> ** CREATE FUNCTION is not supported

I've added support for create and drop function in the attached patch.
Not all commands are rewritten yet though, and not all of them even have
support for the TG_OBJECTID, TG_OBJECTNAME and TG_SCHEMANAME variables.

I think we could still apply that patch + docs and a limited set of
commands, and continue filling the gaps till the end of this cycle. Once
we agree on how to attack the problem at hand, do we really need support
for ALTER OPERATOR FAMILY for an intermediate commit? You tell me.

> * some wrong in deparsing - doesn't support constraints

I've been fixing that and reviewing ALTER TABLE rewriting, should be ok
now. Note that we have to analyze the alter table work queue, not the
parsetree, if we want to normalize automatic constraints names and such
like.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support