Re: htup header reorganization breaks many extension modules - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: htup header reorganization breaks many extension modules
Date
Msg-id 50630ECB.4010400@gmx.net
Whole thread Raw
In response to Re: htup header reorganization breaks many extension modules  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: htup header reorganization breaks many extension modules  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 9/26/12 10:07 AM, Tom Lane wrote:
> I can't get excited about this either.  This isn't the first, or the
> last, change that add-on modules can expect to have to make to track
> newer Postgres versions.  If we allow Peter's complaint to become the
> new project policy, we'll never be able to make any header
> rearrangements at all, nor change any internal APIs.

I'm not saying we can never change anything about the internal headers,
but we can make a small effort not to create useless annoyances.

That said, could someone clarify the header comments in the new headers?We currently have
* htup.h*        POSTGRES heap tuple definitions.
* htup_details.h*        POSTGRES heap tuple header definitions.

The names of the headers don't match their documented purpose very much.Is GETSTRUCT a "detail" of the heap tuple
definition,or is it related
 
to "tuple headers"?  It's not really either, but I guess it is related
to tuple headers because you need to know about the headers to get to
the stuff past it.

When I see headers stuff.h and stuff_details.h, it makes me think that
you should only use stuff.h, and stuff_details.h are internal things.
But a lot of external modules use GETSTRUCT, so they might get confused.




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: system_information.triggers & truncate triggers
Next
From: Tom Lane
Date:
Subject: Re: Oid registry