Query regarding function cleanup in extension upgrade path
Hi PostgreSQL Community,
I have been working on a few extensions but got confused in the upgrade
scenario.
To ask the question let me give a hypothetical example:-
Suppose we have an extension named xyz with version 1.0. It has
xyz--1.0.sql and xyz.c file. I have declared a function named fun() in the
xyz--1.0.sql file and its definition in the xyz.c file.
Now I want to drop this function in the next upgrade i.e. xyz--1.0--1.1 so
I will use DROP FUNCTION fun(); in it and remove the definition from the
xyz.c file.
Here my doubt is wouldn't xyz--1.0 complain about the missing definition of
fun() and if yes how can I clean up my function definition in the xyz.c
file?
I had earlier asked the same question in DBS StackExchange
<https://dba.stackexchange.com/questions/335645/how-to-drop-a-function-in-postgres-extension-upgrade-script-with-required-cleanu?noredirect=1#comment653807_335645>
but didn't get any reply hence trying my luck here.
Regards
Ayush Vatsa
Amazon Web Services (AWS)
Ayush Vatsa <ayushvatsa1810@gmail.com> writes:
To ask the question let me give a hypothetical example:-
Suppose we have an extension named xyz with version 1.0. It has
xyz--1.0.sql and xyz.c file. I have declared a function named fun() in the
xyz--1.0.sql file and its definition in the xyz.c file.
Now I want to drop this function in the next upgrade i.e. xyz--1.0--1.1 so
I will use DROP FUNCTION fun(); in it and remove the definition from the
xyz.c file.
Here my doubt is wouldn't xyz--1.0 complain about the missing definition of
fun() and if yes how can I clean up my function definition in the xyz.c
file?
Yeah, you can't really remove the C extern symbol ever. You can
reduce the C function to a stub that just throws a not-supported
error, perhaps, but your users won't necessarily appreciate that.
It's usually better to make the shlib capable of supporting both
the 1.0 and 1.1 APIs, so that users aren't forced into updating
the extension's SQL declarations immediately.
If you look at the standard contrib modules, you'll find a number
of cases where there are backwards-compatibility functions that
just exist to support people who're still using an older version
of the extension's SQL declarations. Those are likely to remain
there indefinitely.
regards, tom lane
Hi Tom thanks for the answer,
Just two follow up queries regarding this -
1. Suppose I created a new version 1.1 in which I reduce the C function to
throw an error then ship it, will users get the .c latest file immediately
and their old function will throw error but they have to use ALTER
EXTENSION xyz UPGRADE TO 1.1 to use the latest objects defined in 1.1.sql.
Is this the correct understanding?
2. While going through the contrib folder I find that in the regress test
there are two .out files with respect to a single .sql file, example
citext.out and citext_1.out wrt citext.sql. Why is it so? Even in git blame
, I couldn't find much!
Regards
Ayush Vatsa
Amazon Web Services (AWS)
On Wed, 14 Feb 2024 at 22:07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Ayush Vatsa <ayushvatsa1810@gmail.com> writes:
To ask the question let me give a hypothetical example:-
Suppose we have an extension named xyz with version 1.0. It has
xyz--1.0.sql and xyz.c file. I have declared a function named fun() inthe
xyz--1.0.sql file and its definition in the xyz.c file.
Now I want to drop this function in the next upgrade i.e. xyz--1.0--1.1so
I will use DROP FUNCTION fun(); in it and remove the definition from the
xyz.c file.
Here my doubt is wouldn't xyz--1.0 complain about the missing definitionof
fun() and if yes how can I clean up my function definition in the xyz.c
file?Yeah, you can't really remove the C extern symbol ever. You can
reduce the C function to a stub that just throws a not-supported
error, perhaps, but your users won't necessarily appreciate that.
It's usually better to make the shlib capable of supporting both
the 1.0 and 1.1 APIs, so that users aren't forced into updating
the extension's SQL declarations immediately.If you look at the standard contrib modules, you'll find a number
of cases where there are backwards-compatibility functions that
just exist to support people who're still using an older version
of the extension's SQL declarations. Those are likely to remain
there indefinitely.regards, tom lane
Ayush Vatsa <ayushvatsa1810@gmail.com> writes:
Just two follow up queries regarding this -
1. Suppose I created a new version 1.1 in which I reduce the C function to
throw an error then ship it, will users get the .c latest file immediately
and their old function will throw error but they have to use ALTER
EXTENSION xyz UPGRADE TO 1.1 to use the latest objects defined in 1.1.sql.
Is this the correct understanding?
Yes, if you do it like that then once they install the new shlib their
function will be broken until they do ALTER EXTENSION UPGRADE.
2. While going through the contrib folder I find that in the regress test
there are two .out files with respect to a single .sql file, example
citext.out and citext_1.out wrt citext.sql. Why is it so? Even in git blame
, I couldn't find much!
We use that when the expected test output is environment-dependent.
If the diff between the .out files isn't pretty self-explanatory,
you can try checking the git log for the "_1.out" file to see why it
was created.
regards, tom lane
On 14 Feb 2024, at 21:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ayush Vatsa <ayushvatsa1810@gmail.com> writes:
2. While going through the contrib folder I find that in the regress test
there are two .out files with respect to a single .sql file, example
citext.out and citext_1.out wrt citext.sql. Why is it so? Even in git blame
, I couldn't find much!We use that when the expected test output is environment-dependent.
If the diff between the .out files isn't pretty self-explanatory,
you can try checking the git log for the "_1.out" file to see why it
was created.
Some further details on this may be gleaned from the pg_regress source code
where it checks for an alternate file (_1 through _9) in case the main expected
output file created a diff:
--
Daniel Gustafsson