Re: a proposal for an extendable deparser

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

In response to

Browse pgsql-hackers by date

  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