Re: get_whatever_oid, part 1: object types with unqualifed names - Mailing list pgsql-hackers

From Tom Lane
Subject Re: get_whatever_oid, part 1: object types with unqualifed names
Date
Msg-id 29764.1277744412@sss.pgh.pa.us
Whole thread Raw
In response to Re: get_whatever_oid, part 1: object types with unqualifed names  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: get_whatever_oid, part 1: object types with unqualifed names  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jun 28, 2010 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, the whatever_exists() things would just be one-liner macros
>> declared in the same headers that declare the underlying
>> get_whatever_oid() functions. �So the cost of carrying ones that happen
>> to not be used would be nil.

> True, but I think there's a pretty high chance that they woudn't get
> used even in places where they ought to, for lack of existing
> examples, or that new code would fail to add matching macros for new
> object types.  Even so, it's not a terrible idea; I just don't think
> it should be a requirement for this particular patch.  And to be
> honest, I'd sort of like to see how this shakes out before going too
> much further with it.

Well, once you've finished the get_whatever_oid() patch it won't be
hard to count how many instances of OidIsValid(get_whatever_oid()) there
are.  If there's more than a few then I think the macros would be
appropriate to provide.

> Another, and related idea that I had while looking at this is that a
> lot of object types could benefit from a get_whatever_heaptuple()
> function with the same calling syntax.  get_whatever_oid() could be
> restructured to use it, and most object types would have other
> callers, also.  But that too seems like opening a larger can of worms
> than I really want to get into at this point.

This is the sort of thing that I think we should get right the first
time, rather than have multiple waves of large-scale changes.

I'm actually inclined to think we should try to land this stuff in 9.0
if we're going to do it at all.  As a new committer, I suspect you do
not realize exactly how much pain this sort of thing inflicts on
back-patchers.  The SearchSysCache call convention changes have already
ensured that the 8.4 to 9.0 crossover is going to be a major, major PITA
for back-patching, probably nearly as bad as the 8.1 changes in
pgindent's comment wrapping rules.  (If I had it to do over I'd have
vetoed those changes --- I don't even want to think about how many
man-days I've lost to that completely useless cosmetic change.)  This
proposed change will touch many of the same places that were already
modified for that.  It'd be nice to have only one version boundary
where we're manually adjusting back-patched fixes, and not two.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Admission Control
Next
From: Josh Berkus
Date:
Subject: Re: Keepalive for max_standby_delay