Open YChapran opened 3 years ago
I believe there are possibly two issues here. The first is that, although we would like to dbtoyaml
to be run by any PG user, it is sometimes not possible. In general, Pyrseas only queries the system catalogs which AFAIK are always visible to any user. However, in some cases we have to fetch some data from objects (e.g., sequences before PG 10, see objects/table.py
line 134) or using PG system functions/conversions that enforce privileges and restrictions. I think this is the case here (see objects/table.py
line 169). That query could, perhaps, be deconstructed to sidestep the privileges, but it would be (a) less efficient and (b) less maintainable. Nevertheless, dbtoyaml
should probably be modified to catch the InsufficientPrivilege exception and report the problem with a more user friendly message.
The second potential issue is that, even if dbtoyaml
is run from an admin account that doesn't run into the privilege problem, the output may not be according to expectations. This is a conjecture on my part.
Thank you for the quick feedback.
What for do you need the information from the schemas defined to skip? Assume, farther you drop information related to the schemas you are not interested in. From this view reading extra that is just finally dropped is already a high performance penalty.
As for me, this is a bug with the '-N' parameter as it states that specified schema is going to be avoided - Does not extract schema matching schema.
.
Extract was perhaps not the best word to use. Since the general use case for Pyrseas is to deal with a whole database, we always retrieve "all" catalog data ("all" is in quotes because most system objects are excluded but that does cause other problems). Schemas may be useful constructs for DBAs to segregate tables and other objects into seemingly neat "rooms", but PG allows connections between these "rooms" in arbitrary ways. There's nothing preventing a DBA from defining a table in schema A, a related sequence in schema B and a trigger function on the table in schema C. So Pyrseas fetches everything first, and then on output determines what ought to be "extracted". For example, if you run dbtoyaml -t sometable
, it will (or should) output not only the sometable
definition but a someseq
sequence (assuming it's related to sometable
) even if it's defined in a different schema (BTW, this is the way that pg_dump
behaves also), because otherwise you could not use the YAML output to recreate the table and its sequence in another database.
Sequences processing doesn't skip schemas defined with '-N' option, as a result in the case the DB has restricted rights and I'm not interested in the restricted schemas the dbtoyaml fails on retrieval of information for Sequences from the restricted scheme.
Steps:
Result:
Expected: As restrictedSchemaName is set to be skipped no data related to this schema should be read from the DB. The yaml file printed to stdout.