Deparsing DDL command strings - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Deparsing DDL command strings
Date
Msg-id m2zk41m6e7.fsf@2ndQuadrant.fr
Whole thread Raw
Responses Re: Deparsing DDL command strings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 road blocker for now is best summarized by the
following comment in src/backend/commands/tablecmds.c
   * Now add any newly specified column default values and CHECK constraints   * to the new relation.  These are passed
tous in the form of raw   * parsetrees; we need to transform them to executable expression trees   * before they can be
added.The most convenient way to do that is to   * apply the parser's transformExpr routine, but transformExpr doesn't
* work unless we have a pre-existing relation. So, the transformation has   * to be postponed to this final step of
CREATETABLE.
 

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. 

Should I work on transformExpr() so that it knows how to work with a non
existing relation, or should I write a new transformRawExpr() that knows
how to handle this case?

Or do we want to limit the deparsing feature and not accept some CHECK
and DEFAULT expressions (though not being able to cope with T_A_Const is
a bummer)? (I don't mean to do it, I still have to mention the choice).

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



pgsql-hackers by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: Missing OID define
Next
From: zafer yagmuroglu
Date:
Subject: FW: PQntuples and PQgetvalue problem.