Re: pg_dump, libdump, dump API, & backend again

Philip Warner writes:

> 1. Can anyone think of an existing utility or library in PG that would
> profit from a more convenient interface for querying metadata than is
> available from ODBC or the pg_* tables?

People do ask all the time how they can reproduce psql's, say, "\d" output
for themselves. Notice that they don't ask how to reproduce pg_dump's
output, pg_dump does that just fine, but people want to get at the
metadata and process it for themselves. I imagine people have web tools
for modelling their databases, etc. or change tables on the fly. I'd say
there is a big market for this sort of thing, and the current state of
affairs that every system catalog change is in some way liable to break
all these applications is a non-negligible problem.

It is therefore my opinion that making SQL dumps widely available is,
while certainly useful, not the real core of the problem. Getting to the
data that underlies the dump is. Anything that does that would be a step
ahead.

Some things to consider:

* A backend-side implementation: we already have a couple of views to that
effect (pg_rules, pg_views). You can always add more.

* A C API: How many people do use C? How to propagate this to other
interfaces? Are we really up to creating and maintaining another
hand-crafted API?

> 4. Even if I achieve nothing more than breaking 'libdump' out of pg_dump,
> and adding a \D command to psql, does anybody object to this as an objective?

If that's your concern that you can just link a couple of pg_dump's object
files into psql. You could perhaps create a de facto API within pg_dump,
which would also go a long way in cleaning up pg_dump's source code.

(When I was wheeling and dealing in psql last fall I was faced with the
same questions regarding the table printing facilities. People are not
really interested in getting pretty printed ASCII versions of their query
results; their web browser or widget set can do that much better. And even
those that do wouldn't like the particular formatting choices anyway. So I
withdrew psql's printing functions from the public. You can still link in
print.o into your program if you want to, but please don't complain if I
change the spacing and your application breaks.)

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden