From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bug? |
Date: | 2002-09-09 16:33:23 |
Message-ID: | 3D7CCD53.8060205@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>>Joe Conway <mail(at)joeconway(dot)com> writes:
>>
>>>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:
>>
>
>>ISTR deciding that that was okay, and there was no need to clutter
>>LookupExplicitNamespace with an extra parameter. Don't recall the
>>reasoning at the moment...
>
>
> After looking: the only place that calls RangeVarGetRelid with a "true"
> second parameter is tcop/utility.c, and it just does it so that it can
> give a different error message for the "relation not found" case. Thus,
> we don't actually *want* failures other than "relation not found" to
> return from RangeVarGetRelid. So the code is right as-is. Perhaps the
> comments could stand improvement though, to make it clearer what failOK
> is meant to do.
OK. The reason I brought it up was that while working on the plpgsql patch
(posted last night), I found that plpgsql gives a better error message if
RangeVarGetRelid returns InvalidOid instead of simply elog'ing. The comments
did lead me to believe I could get an InvalidOid, so I was surprized when I
didn't.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Brett Schwarz | 2002-09-09 16:41:15 | Re: Script to compute randon page cost |
Previous Message | Nick Fankhauser | 2002-09-09 16:25:08 | Re: Script to compute random page cost |