On Tue, Apr 10, 2012 at 06:16:31PM -0400, Robert Haas wrote: > On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
