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. +
