Class dependencies
Hi,
Is it safe to assume all objects of a given class can be
dropped/created, provided all objects of a list of other classes have
already been dropped/created?
I'm looking at http://developer.postgresql.org/pgdocs/postgres/catalogs.html
For each class, a list of "References" are defined, i.e. other classes
the given class depend on.
For instance, is it correct to assume constraints always can be
dropped, i.e. no other class (nor other constraints) can depend on
them?
--
Best regards,
Joel Jacobson
Glue Finance
On 2011-01-10, Joel Jacobson <joel@gluefinance.com> wrote:
Hi,
Is it safe to assume all objects of a given class can be
dropped/created, provided all objects of a list of other classes have
already been dropped/created?I'm looking at http://developer.postgresql.org/pgdocs/postgres/catalogs.html
For each class, a list of "References" are defined, i.e. other classes
the given class depend on.
For instance, is it correct to assume constraints always can be
dropped, i.e. no other class (nor other constraints) can depend on
them?
As I unserstand it a references constraint requires a unique
constraint on the referred-to expressiom.
table a (b,c) references d(e,f)
requires
unique (e,f) on table d
--
⚂⚃ 100% natural
Jasen Betts <jasen@xnet.co.nz> writes:
On 2011-01-10, Joel Jacobson <joel@gluefinance.com> wrote:
Is it safe to assume all objects of a given class can be
dropped/created, provided all objects of a list of other classes have
already been dropped/created?
For instance, is it correct to assume constraints always can be
dropped, i.e. no other class (nor other constraints) can depend on
them?
As I unserstand it a references constraint requires a unique
constraint on the referred-to expressiom.
Another problem for this type of scheme is circular dependencies.
There are for example circular dependencies between a type and its
I/O functions. pg_dump contains some heuristics for resolving the
kinds of circular dependencies that are known to exist.
regards, tom lane