Re: code cleanup for SearchSysCache

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: code cleanup for SearchSysCache
Date: 2006-06-09 02:25:07
Message-ID: 4930.1149819907@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas DCP SD 2006-06-09 07:14:57 Re: More on inheritance and foreign keys
Previous Message Christopher Browne 2006-06-09 02:10:06 Re: Fabian Pascal and RDBMS deficiencies in fully implementing the relational model