bug?

From: Joe Conway <mail(at)joeconway(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: bug?
Date: 2002-09-08 06:19:19
Message-ID: 3D7AEBE7.9090200@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I found the following while poking around. RangeVarGetRelid takes a
second parameter that is intended to allow it to not fail, returning
InvalidOid instead. However it calls LookupExplicitNamespace, which does
not honor any such request, and happily generates an error on a bad
namespace name:

/*
* RangeVarGetRelid
* Given a RangeVar describing an existing relation,
* select the proper namespace and look up the relation OID.
*
* If the relation is not found, return InvalidOid if failOK = true,
* otherwise raise an error.
*/
Oid
RangeVarGetRelid(const RangeVar *relation, bool failOK)
{
[...]
if (relation->schemaname)
{
/* use exact schema given */
namespaceId = LookupExplicitNamespace(relation->schemaname);
relId = get_relname_relid(relation->relname, namespaceId);
}
[...]
}

Oid
LookupExplicitNamespace(const char *nspname)
{
[...]
namespaceId = GetSysCacheOid(NAMESPACENAME,
CStringGetDatum(nspname),0, 0, 0);
if (!OidIsValid(namespaceId))
elog(ERROR, "Namespace \"%s\" does not exist", nspname);
[...]
}

Shouldn't LookupExplicitNamespace be changed to allow the same second
parameter? All uses of LookupExplicitNamespace, besides in
RangeVarGetRelid, would have the parameter set to false.

Comments?

Joe

Responses

  • Re: bug? at 2002-09-09 13:33:54 from Tom Lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2002-09-08 08:20:11 7.3beta and ecpg
Previous Message Matthew T. O'Connor 2002-09-08 04:25:30 Re: --with-maxbackends