Re: erroneous restore into pg_catalog schema
От | Robert Haas |
---|---|
Тема | Re: erroneous restore into pg_catalog schema |
Дата | |
Msg-id | CA+TgmoYuU31LoMBAjfyyXPj12CCUrVfpCfJM+pdcp79YvTV7MA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: erroneous restore into pg_catalog schema (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: erroneous restore into pg_catalog schema
|
Список | pgsql-hackers |
On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Robert Haas escribió: >> On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > Robert Haas <robertmhaas@gmail.com> writes: >> >> Or perhaps there is some other way to make sure that the user "really >> >> meant it", like refusing to create in pg_catalog unless the schema >> >> name is given explicitly. I kind of like that idea, actually. >> > >> > That does seem attractive at first glance. Did you have an >> > implementation in mind? The idea that comes to mind for me is to hack >> > namespace.c, either to prevent activeCreationNamespace from getting set >> > to "pg_catalog" in the first place, or to throw error in >> > LookupCreationNamespace and friends. I am not sure though if >> > LookupCreationNamespace et al ever get called in contexts where no >> > immediate object creation is intended (and thus maybe an error wouldn't >> > be appropriate). >> >> As far as I can see, the principle place we'd want to hack would be >> recomputeNamespacePath(), so that activeCreationNamespace never ends >> up pointing to pg_catalog even if that's explicitly listed in >> search_path. The places where we actually work out what schema to use >> are RangeVarGetCreationNamespace() and >> QualifiedNameGetCreationNamespace(), but those don't seem like they'd >> need any adjustment, unless perhaps we wish to whack around the "no >> schema has been selected to create in" error message in some way. > > Robert, are you working on this? I wasn't, but I can, if we agree on it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: