From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Dave Gudeman <dave(dot)gudeman(at)gmail(dot)com>, Postgres <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: a proposal for an extendable deparser |
Date: | 2009-03-02 15:29:35 |
Message-ID: | 5807.1236007775@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Dave Gudeman wrote:
>> I don't need to add new node types or add any syntax; it is the output that
>> I'm concerned with. What I want is a way to print a tree according to some
>> pretty strict rules. For example, I want a special syntax for function RTEs
>> and I don't want the v::type notation to be output (the flag to turn it off
>> doesn't do what I want).
> This will become useful for SQL/MED connectors to other databases. Other
> DBMSs have slightly different syntax, and with something like this you
> could still use ruleutils.c for the deparsing, but tweak it slightly for
> the target database.
That all sounds like pie in the sky to me. It's unlikely that you could
produce any specified syntax with just minor changes to the dumping of a
node type or two --- the node structure is specific to Postgres' view of
the world and won't necessarily be amenable to producing someone else's
syntax.
On the whole, "copy and paste ruleutils" seems like a sufficient answer
to me. Maybe when we have a couple of examples of people having to do
that, we can figure out an abstraction that solves the problem better;
but I have no confidence that the mechanism Dave proposes will help
or will be worth the trouble to implement.
An even more likely answer is "patch ruleutils so it has an extra flag
that does what you want". We might or might not be willing to take such
a patch back into core, but it sure seems like a lot less work.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-03-02 16:55:50 | Re: regression test crashes at tsearch |
Previous Message | Teodor Sigaev | 2009-03-02 15:15:25 | Re: regression test crashes at tsearch |