From: | "Regina Obe" <lr(at)pcorp(dot)us> |
---|---|
To: | "'Robert Haas'" <robertmhaas(at)gmail(dot)com> |
Cc: | "'Andreas Karlsson'" <andreas(at)proxel(dot)se>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Is there a way around function search_path killing SQL function inlining? - and backup / restore issue |
Date: | 2016-03-10 21:29:39 |
Message-ID: | 004401d17b13$f42add60$dc809820$@pcorp.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Hmm. The meaning of funcs.inline depends on the search_path, not just during dump restoration but all the time. So anything uses it under a different search_path setting than the normal one will have this kind of problem; not just
> dump/restore.
> I don't have a very good idea what to do about that.
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
I wasn't suggesting it was a restore only issue, but it's most felt when your data doesn't come back. It affects any extension that relies on another extension.
Take for example, I have tiger geocoder which relies on fuzzystrmatch. I have no idea where someone installs fuzzystrmatch so I can't schema qualify those calls. I use that dependent function to use to build an index on tables.
The indexes don't come back. What I was trying to suggest (side topic, forget about inline issue),
Is the pg_dump should have a switch to allow users to tack on extra schemas
So that the dump restore set search_path thing looks like:
Set search_path=my_data_schema, pg_catalog, whatever_otehr_schemas_I_have_for_db
People can choose to use that switch or not. So that way if people do have database search_paths, they normally run with, their data will come back.
Am I missing something here in this suggestion? It's one of the most common complaints I hear about PostgreSQL in general and the crazy things people do to get around the issue like doing plain text dumps and parsing the dump.
Thanks,
Regina
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-03-10 21:51:03 | Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity. |
Previous Message | Andres Freund | 2016-03-10 21:27:57 | Re: checkpointer continuous flushing - V18 |