Philip Warner writes:
> I would have thought that pgaccess would still need to display table
> definitions in SQL, but I have not looked at it closely enough. At the
> lowest level I suspect pgaccess will always have to use direct access to
> pg_* tables.
I thought it was your intention to get rid of this fact. We should
certainly be thinking in terms of all client applications.
[Information Schema]
> This sounds good; where are they defined in the spec?
Part 2, chapter 20, if that helps you. It's not really possible to
implement all of these at this point because many are quite complex and
depend on outer joins and other fancy features, or contain
meta-information on features that don't exist yet. Actually, we probably
need the full-blown TOAST before some of these will fit at all.
> Presumably they could be called pg_*...
We could name them pg_IS_* for the moment and add simplistic parser
support for schemas that wiil pick up these tables if the
information_schema is referenced.
> This is the sort of thing I'd like to see, but on a more general level:
>
> format_object('table', <oid>)
>
> would return the base definition of the table.
I'm not sure if we want to move the entire pg_dump functionality into the
backend. For example, if someone wants to move SQL dumps to a
not-quite-SQL or a much-more-SQL database and the format is slightly
wrong, then there's no way to amend that short of patching the backend.
Then we could as well have the backend returns pre-formatted output for
psql.
A human-oriented layer over the system catalogs (which are implementation
oriented) could go a long way toward maximum flexibility.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
