| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | "Igal (at) Lucee(dot)org" <igal(at)lucee(dot)org> |
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: pg_dump and search_path |
| Date: | 2019-07-09 14:49:24 |
| Message-ID: | CAKFQuwZ+s3chtdwhNPG5HZSaKx55qkfCWLY+q1LDdWpw2FGkLA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Jul 9, 2019 at 7:41 AM Igal @ Lucee.org <igal(at)lucee(dot)org> wrote:
> search_path is not set int he config, but rather with ALTER DATABASE SET
> search_path TO ... but I have executed that prior to the RESTORE on the
> target database. Would it make a difference if I set it in the config?
>
What is your restore command then? Because if you are dropping and
recreating the same named database the ALTER DATABASE SET command is going
to be lost with the drop since it is associated to an OID and not just the
name. By placing the search_path into postgres.conf you avoid that issue
altogether.
But, yes, objects saved to the database should usually have schema
qualifications (which gets a bit messy with custom operators). search_path
reliance should probably be reserved to interactive use or at worse client
supplied queries.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Igal @ Lucee.org | 2019-07-09 15:48:44 | Re: pg_dump and search_path |
| Previous Message | Igal @ Lucee.org | 2019-07-09 14:41:37 | Re: pg_dump and search_path |