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