Time to fully remove heap_formtuple() and friends?

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Time to fully remove heap_formtuple() and friends?
Date: 2015-06-13 00:15:53
Message-ID: CAM3SWZTXu9LfUx7SR3XN+s2Dos+1Y+pP3E0qgGb5h1Ei89GUEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
remove-legacy-formtuple.patch text/x-patch 5.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message deavid 2015-06-13 01:17:49 Re: Is it possible to have a "fast-write" Index?
Previous Message Peter Geoghegan 2015-06-12 23:32:22 Re: Further issues with jsonb semantics, documentation