Open andreypopp opened 4 years ago
From a theoretical standpoint, I think dbtoyaml -t
should output everything that's related to the requested table(s), but that is easier said than done. As I recall, one of the early issues was that if a table had a related sequence due to the use of SERIAL, dbtoyaml
was only outputting the table so yamltodb
would fail when it tried to ALTER TABLE to add the sequence. So that was fixed as a separate issue (there is a complicated if
at the beginning of Sequence.to_map()
that IIRC attests to that).
So, dbtoyaml -t
doesn't currently output related types such as ENUMs (nor DOMAINs or TYPEs). I don't think we were trying to explicitly emulate pg_dump
behavior (which also doesn't). Could it be done? I believe so, but it may not be as also outputting related SEQUENCEs. Since @dvarrazzo refactored Pyrseas for dependencies, we have dependency graphs for each object, so one could traverse the graph for a requested table and add to a list of "also needed" objects any data type that wouldn't normally be expected in a PG database. A quick and dirty (and more specific) solution would be to loop through the columns of a table, e.g., the film
table in the pagila
sample database, and add to a list of related objects any column type that's not in a list of "common" datatypes (INTEGER, TEXT, TSVECTOR, etc.), e.g., in the pagila case, the DOMAIN year
and the ENUM mpaa_rating
.
I understand that
dbtoyaml
is modelled afterpg_dump
andpg_dump
doesn't extract enums if you supply-t
but I'm wondering ifdbtoyaml
should diverge here? What do you think.My use case is that I have a tool to build new pg databases out of existing ones and one of the features I want is to selectively to dump/restore (selectively as by specifying a subset of tables).
pg_dump
doesn't work for me (for the reason above) but I was wondering if I can usedbtoyaml
instead for that.