Re: get_whatever_oid, part 1: object types with unqualifed names

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