Should "dbtoyaml -t TABLE" extract enum types as well

[andreypopp]

I understand that dbtoyaml is modelled after pg_dump and pg_dump doesn't extract enums if you supply -t but I'm wondering if dbtoyaml 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 use dbtoyaml instead for that.

[jmafc]

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.