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 <t...@sss.pgh.pa.us> wrote: > Ayush Vatsa <ayushvatsa1...@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 >
