Martijn van Oosterhout <kleptog@svana.org> writes:
> Really? The code creates ordinary types, operators and functions, all
> of which are dumped fine by pg_dump. Dependancies are created which
> should ensure the parts get dumped in the right order. What special
> support in pg_dump were you envisioning?
The dump should look the same as the commands originally used to create
the type, which is surely not going to happen with that "SELECT
create_tagged_type()" stuff barring pg_dump modifications. Otherwise
we are nailing down not one but two representations of this feature that
we'll have to support forevermore: what the users see and what's in
pg_dump scripts. We've already learned that lesson the hard way several
times, and are still trying to cope with the fallout in some places
(serial columns for instance).
Now I happen to think that SELECT create_tagged_type() is a horrid kluge
anyway ;-) so I'm not proposing that pg_dump be changed to output that.
What we would need is to design a command syntax that we're actually
prepared to live with for the indefinite future, then implement it in
the backend and teach pg_dump about it.
What we *don't* want is a pg_dump representation that exposes
implementation details. I would classify both the backing table for a
tagged type's enum values, and the representation of its operators and
functions, as implementation details.
BTW, I share Andrew Dunstan's feeling that there's huge overlap here
with support for mysql-like enum types. We ought to try to kill that
bird with the same stone.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
