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

On Mon, Jun 28, 2010 at 12:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jun 28, 2010 at 12:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> True.  Is it worth providing whatever_exists() macros that wrap
>>> get_whatever_oid() like this, just so that callers are a bit clearer as
>>> to what they're doing?
>
>> I haven't made a detailed study of this issue, so I'm not 100% sure.
>> My gut feeling however is that nearly all of the callers need the OID,
>> and that some of the whatever_exists() functions wouldn't have any
>> callers at all.  Which makes me pretty hesitant to add them,
>> especially given our decision not to centralize all the
>> get_whatever_oid() functions in one place.
>
> 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.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company