Philip Warner <pjw@rhyme.com.au> writes:
> I would have thought that the database itself should be the tool used to
> display SQL, and if not the database, then one of the interface libraries.
You might be on to something. We have bits and pieces of that, such as
the rule reverse-lister and the code Peter just added to create a
readable version of a type name, but maybe some more consolidation is
in order.
> The separation would have the further advantage that when a new language
> feature is added the person adding it does not have to remember to update
> pg_dump, psql etc. And the task might be a little easier, since I would
> hope that the code to dump the definition would be close to the code to
> parse it.
No, not really. The only advantage would be in centralizing the display
capability and having just one copy instead of several. That is a
substantial advantage, but you only get it if you make sure the backend
display capability is defined in a way that lets all these apps use it.
That might take some careful thought. For example, does the definition
of a table include associated constraints and indexes? pg_dump would
want them separate, other apps perhaps not. Also, psql's \d command
doesn't display the schema of a table in the form of a CREATE command
to recreate it, and I don't think it should. Certainly you don't want
to condemn every app that wants to know "what are the columns of this
table" to have to include a full SQL parser to make sense of the
answer. So I think some thought is needed to figure out what a
general-purpose representation would be like.
regards, tom lane