Thread: 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@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. +