Thread: Deprecating heap_formtuple/heap_modifytuple/heap_deformtuple

Deprecating heap_formtuple/heap_modifytuple/heap_deformtuple

From
Gregory Stark
Date:
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


Re: Deprecating heap_formtuple/heap_modifytuple/heap_deformtuple

From
Bruce Momjian
Date:
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@postgresql.org so that your
>        message can get through to the mailing list cleanly

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +