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

Philip Warner writes:

> 2. How can we provide a function in psql that displays definitions of all
> things that a user can create with SQL?
>
> This is the problem I set out to address, which is why I looked at using
> pg_dump code. Which then led me to the philosophical question of what
> should be responsible for 'decompiling' the internal representation of the
> metadata. My feeling is that the backend 'compiles' SQL into metadata, so
> it should also decompile it.

There is certainly an intellectual merit in making the backend spit out
the SQL it took in. But, just for kicks, there is also an intellectual
merit in *not* doing it: Whatever you dump represents the state of a
database, but SQL only provides a method for modifying the state, not for
representing it. The backend has, by and large, no idea how it got to the
current state. Which is the philosophical counter-argument to the notion
that the backend should also provide the inverse operation to its query
parser -- there is no inverse.

Getting of that high horse, the practical problems I see is that there are
about a thousand parameters which would affect how you dump the SQL:

* indentation
* capitalization
* quotes
* standards compliance (to migrate to a different RDBMS)
* order
* view as view, view as rule?
* with/without psql specific stuff (\connect ...)
* How to resolve circular dependencies?

These kinds of decisions are better off with a client application, ISTM.

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