Re: Query regarding function cleanup in extension upgrade path

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ayush Vatsa <ayushvatsa1810(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Query regarding function cleanup in extension upgrade path
Date: 2024-02-14 16:37:37
Message-ID: 2899690.1707928657@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ayush Vatsa <ayushvatsa1810(at)gmail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2024-02-14 16:39:36 Re: PostgreSQL DB in prod, test, debug
Previous Message Ayush Vatsa 2024-02-14 16:28:29 Query regarding function cleanup in extension upgrade path