Time to fully remove heap_formtuple() and friends?

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Time to fully remove heap_formtuple() and friends?
Дата
Msg-id CAM3SWZTXu9LfUx7SR3XN+s2Dos+1Y+pP3E0qgGb5h1Ei89GUEw@mail.gmail.com
обсуждение исходный текст
Ответы Re: Time to fully remove heap_formtuple() and friends?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Further issues with jsonb semantics, documentation
Следующее
От: deavid
Дата:
Сообщение: Re: Is it possible to have a "fast-write" Index?