Deprecating heap_formtuple/heap_modifytuple/heap_deformtuple

I think we should go ahead and kill the old 'n'/' ' api for heaptuple.c. The
code duplication here is really annoying and it makes it confusing for
developers trying to read or write code where they have to keep straight which
interface they're using.

What I think we should do is just announce they're deprecated for 8.3 without
changing anything and then early in 8.4 remove them and convert our own code
to use the new api. We could add wrappers prior to the 8.4 release which
converts the isnull/replaces arrays for the benefit of outside modules.

As an exercise I just went ahead and removed all of our calls to it and while
it was quite annoying there weren't really any show-stoppers. The worst thing
I find is that SPI uses a similar interface which means it'll be inconsistent
with the underlying interface -- but there's no direct binding between the two
so it doesn't cause any actual breakage, just potential confusion.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Added to TODO:

* Remove old-style routines for manipulating tuples

http://archives.postgresql.org/pgsql-hackers/2007-10/msg00851.php

---------------------------------------------------------------------------

Gregory Stark wrote:
>
> I think we should go ahead and kill the old 'n'/' ' api for heaptuple.c. The
> code duplication here is really annoying and it makes it confusing for
> developers trying to read or write code where they have to keep straight which
> interface they're using.
>
> What I think we should do is just announce they're deprecated for 8.3 without
> changing anything and then early in 8.4 remove them and convert our own code
> to use the new api. We could add wrappers prior to the 8.4 release which
> converts the isnull/replaces arrays for the benefit of outside modules.
>
> As an exercise I just went ahead and removed all of our calls to it and while
> it was quite annoying there weren't really any show-stoppers. The worst thing
> I find is that SPI uses a similar interface which means it'll be inconsistent
> with the underlying interface -- but there's no direct binding between the two
> so it doesn't cause any actual breakage, just potential confusion.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +