Re: pg_dump, libdump, dump API, & backend again
От | Peter Eisentraut |
---|---|
Тема | Re: pg_dump, libdump, dump API, & backend again |
Дата | |
Msg-id | Pine.LNX.4.21.0007220241270.361-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | pg_dump, libdump, dump API, & backend again (Philip Warner <pjw@rhyme.com.au>) |
Список | pgsql-hackers |
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@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: