Re: code cleanup for SearchSysCache - Mailing list pgsql-hackers

From Tom Lane
Subject Re: code cleanup for SearchSysCache
Date
Msg-id 4930.1149819907@sss.pgh.pa.us
Whole thread Raw
In response to Re: code cleanup for SearchSysCache  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
List pgsql-hackers
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> wrote
>> You'd need two essentially equivalent versions of SearchSysCache, and
>> you'd lose the ability to make the error message identify what was being
>> searched for, so I vote no.

> Both arguments are not necessarily true. This change is quite like what we
> made to hash_search(). There is only one SearchSysCache() which will take an
> extra argument "isComplain" (vs. HASH_ENTER_NULL). The error message can be
> easily identified from the first parameter "cacheId" -- we will add another
> field in struct cachedesc which describs the cache name.

I think you misunderstood my second point: you might want a custom error
message for a particular usage.

The bottom line though is I don't see this as a useful improvement, and
given the amount of code it will break (both inside and outside our
CVS), marginal niceness isn't a good enough reason to change.  If we had
another reason forcing a change in SearchSysCache's API, then maybe we'd
do this at the same time, but I can't see doing it by itself.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Qingqing Zhou"
Date:
Subject: Re: code cleanup for SearchSysCache
Next
From: "Zeugswetter Andreas DCP SD"
Date:
Subject: Re: More on inheritance and foreign keys