Oh, I understood you. Clearly, to surely avoid any side-effect in pg_dump,
all IMMUTABLE functions must implicitly assign search_path in develop time.
It's not obvious, so I propose to include this in CONSTRAINT ... CHECK and
CREATE INDEX documentation. :-) Or - raise NOTICE if an IMMUTABLE
Thank you for a possible solution.
But what about the database which exists and works correctly (and conforms
all the standards from the documentation), but dump+restore sequence is
failed for it? Does it mean that pg_dump should be improved to pass
dump+restore sequence?
Besides that, for
Dmitry Koterov [EMAIL PROTECTED] writes:
Thank you for a possible solution.
But what about the database which exists and works correctly (and conforms
all the standards from the documentation), but dump+restore sequence is
failed for it? Does it mean that pg_dump should be improved to pass
Hello.
Why pg_dump dumps CONSTRAINT ... CHECK together with CREATE TABLE queries,
but NOT at the end of dump file (as FOREIGN KEY)?
Sometimes it causes the generation of invalid dumps which cannot be
restored. Details follow.
1. I use database-dedicated search_path:
ALTER DATABASE d SET
Dmitry Koterov [EMAIL PROTECTED] writes:
3. The function a() calls any OTHER function b() from OTHER namespace (or
uses operators from other namespaces), but does not specify the schema name,
because it is in database search_path:
CREATE FUNCTION a(i integer) RETURNS boolean AS $$
BEGIN
