Time to fully remove heap_formtuple() and friends? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Time to fully remove heap_formtuple() and friends?
Date
Msg-id CAM3SWZTXu9LfUx7SR3XN+s2Dos+1Y+pP3E0qgGb5h1Ei89GUEw@mail.gmail.com
Whole thread Raw
Responses Re: Time to fully remove heap_formtuple() and friends?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Commit 902d1cb3, made in 2008, established that the functions
heap_formtuple(), heap_modifytuple(), and heap_deformtuple() were
deprecated. The commit also actually removed those routines, replacing
them with simple wrappers around their real replacements, which are
spelled slightly differently and have a slightly different interface
(their real replacements are heap_deform_tuple() and friends). The
wrappers fulfilled the old, legacy interface, and were added for
compatibility with third party code -- the old char 'n'/' ' convention
for indicating nulls was bolted on top of calls to the new variants.
Bolting that on to the new variants involves a new palloc() + pfree(),
which isn't cheap.

Attached patch actually removes heap_formtuple() and friends. Does
this seem worthwhile? Does this seem like something that there should
be a compatibility release note item for if we proceed? I have not
added one yet.

I think that enough time has passed that these wrappers are clearly
100% deadwood. If any external extensions are still using
heap_formtuple(), they ought to be updated to work with Postgres 9.5
by using the new variants -- a straight switch-over of callers in the
style of 902d1cb3 should now work against all supported versions of
PostgreSQL, and without macro hacks. Affected external code building
against the removed legacy interface will reliably fail to build,
forcing the third party code to conform in a non-surprising way.
Removing the code seems very low risk.

--
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Further issues with jsonb semantics, documentation
Next
From: deavid
Date:
Subject: Re: Is it possible to have a "fast-write" Index?