Re: [RFC] Common object property boards

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kohei Kaigai <kohei(dot)kaigai(at)emea(dot)nec(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] Common object property boards
Date: 2011-08-07 08:21:21
Message-ID: CADyhKSVBpZB6VdXe_z-K138+R8NNWuPEFCUpp1FN4Rtma2wJXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> So add a bunch of macros on top for the two or three (five?) most common
>>> cases -- say those that occur 3 times or more.
>>
>> I could go for that.
>>
> OK, I'll try to implement according to the idea.
>
I'm under implementation of this code according to the suggestion.
However, I'm not sure whether it is really portable way (at least, GCC accepts),
and whether the interface is simpler than as Robert suggested at first.

extern void get_object_property(ObjectType objtype,
const char **objtype_text,
Oid *relationId,
int *catid_oidlookup,
int *catid_namelookup,
AttrNumber *attnum_name,
AttrNumber *attnum_namespace,
AttrNumber *attnum_owner);

#define get_object_property_attnum_name(objtype) \
({ AttrNumber ____temp; \
get_object_property((objtype), NULL, NULL, NULL, NULL, \
&____temp, NULL, NULL); \
____temp; })
#define get_object_property_attnum_namespace(objtype) \
({ AttrNumber ____temp; \
get_object_property((objtype), NULL, NULL, NULL, NULL, \
NULL, &____temp, NULL); \
____temp; })
#define get_object_property_attnum_ownership(objtype) \
({ AttrNumber ____temp; \
get_object_property((objtype), NULL, NULL, NULL, NULL, \
NULL, NULL, &____temp); \
____temp; })

If get_object_property() returns an entry within the big property table,
the bunch of macros will become simple, as follows:

extern ObjectProperty get_object_property(ObjectType objtype);

#define get_object_property_attnum_name(objtype) \
(get_object_property(objtype)->attnum_name)

2011/8/2 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> 2011/8/2 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Mon, Aug 1, 2011 at 4:27 PM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)com> wrote:
>>> Excerpts from Robert Haas's message of lun ago 01 16:12:56 -0400 2011:
>>>> On Mon, Aug 1, 2011 at 4:02 PM, Alvaro Herrera
>>>> <alvherre(at)commandprompt(dot)com> wrote:
>>>> > Excerpts from Kohei KaiGai's message of dom jul 31 02:21:55 -0400 2011:
>>>> >> 2011/7/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>>> >
>>>> >> > It would likely be better to not expose the struct type, just individual
>>>> >> > lookup functions.
>>>> >> >
>>>> >> If so, individual functions to expose a certain property of the supplied
>>>> >> object type should be provided.
>>>> >>
>>>> >>   int get_object_property_catid_oidlookup(ObjectType);
>>>> >>   int get_object_property_catid_namelookup(ObjectType);
>>>> >>   Oid get_object_property_relation_id(ObjectType);
>>>> >>   AttrNumber get_object_property_nameattnum(ObjectType);
>>>> >>   AttrNumber get_object_property_namespacenum(ObjectType);
>>>> >>   AttrNumber get_object_property_ownershipnum(ObjectType);
>>>> >
>>>> > Maybe a single lookup function that receives pointers that the lookup
>>>> > routine can fill with the appropriate information; allowing for a NULL
>>>> > pointer in each, meaning caller is not interested in that property.
>>>>
>>>> That seems like a lot of extra notational complexity for no particular
>>>> benefit.  Every time someone wants to add a new property to this
>>>> array, they're going to have to touch every caller, and all
>>>> third-party code using this interface will have to be rejiggered.
>>>
>>> So add a bunch of macros on top for the two or three (five?) most common
>>> cases -- say those that occur 3 times or more.
>>
>> I could go for that.
>>
> OK, I'll try to implement according to the idea.
>
> Thanks,
> --
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tim 2011-08-07 08:23:26 Re: vacuumlo patch
Previous Message Hannu Krosing 2011-08-07 07:57:23 Will switchover still need a checkpoint in 9.1 SR Hot Standby