Re: pg_tablespace_location() error message
От | Bruce Momjian |
---|---|
Тема | Re: pg_tablespace_location() error message |
Дата | |
Msg-id | 20120410222441.GH3379@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_tablespace_location() error message (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_tablespace_location() error message
|
Список | pgsql-hackers |
On Tue, Apr 10, 2012 at 06:16:31PM -0400, Robert Haas wrote: > On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Bruce Momjian <bruce@momjian.us> writes: > >> The new pg_tablespace_location() function added in PG 9.2 to remove the > >> director location from pg_tablespace returns an odd error for '0', which > >> is InvalidOID: > > > > Well, it's the same "odd error" you'd get for any other bogus OID. > > > > The way the function is coded, it has no need to look into pg_tablespace > > as such, which is why you don't get something like "no such tablespace". > > We could add such a lookup purely for error detection purposes, but I'm > > not real sure I see the point. > > I think what Bruce might be getting at is that 0 is more likely than a > randomly chosen value to be passed to this function; for example, one > can imagine wanting to pass pg_class.reltablespace. Yes, that was my point. In tracking down a pg_upgrade bug, I discovered that zero means the cluser default location, while pg_tablespace_location() returning '' means the default _database_ (or global) tablespace. We are quite unclear on what DEFAULTTABLESPACE_OID means (the database default). -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: