[[deprecated("don't call this, call that")]]

Started by Thomas Munro5 days ago4 messageshackers

Jump to latest

Thomas Munro

thomas.munro@gmail.com

5 days ago

Hi,

While working on 1e7fe06c, I wished I could make functions generate
compiler warnings:

pg_attribute_deprecated("use pg_mblen_{cstr,range,with_len,unbounded} instead")
extern int pg_mblen(const char *mbstr);

That'd avoid accidental reintroduction, and also get extension
maintainers' attention. $SUBJECT is C23/C++14's syntax, but you've
long been able to do that with in __attribute__ or __declspec for the
usual suspects so I looked into which compiler versions introduced
that and came up with the attached.

The idea would be to back-patch the deprecation warnings, and delete
the functions in, I guess now, v20. Then the deprecation notice
facility would always be there for next time we need it.

Michael Paquier

michael@paquier.xyz

5 days ago

In reply to: Thomas Munro (#1)

Re: [[deprecated("don't call this, call that")]]

On Thu, Apr 09, 2026 at 03:34:30PM +1200, Thomas Munro wrote:

The idea would be to back-patch the deprecation warnings, and delete
the functions in, I guess now, v20. Then the deprecation notice
facility would always be there for next time we need it.

That would be a nice addition, especially with the recent mblen()
business (could have used that a few times myself). So +1 for the
addition of the macro in the back branches.

Do we need to be that conservative with the removal in v19? We could
just pull the deletion switch without waiting for v20, IMO.. With the
deprecated macro in place, at least folks would be aware of the
problem.
--
Michael

Peter Eisentraut

peter_e@gmx.net

5 days ago

In reply to: Thomas Munro (#1)

Re: [[deprecated("don't call this, call that")]]

On 09.04.26 05:34, Thomas Munro wrote:

While working on 1e7fe06c, I wished I could make functions generate
compiler warnings:

pg_attribute_deprecated("use pg_mblen_{cstr,range,with_len,unbounded} instead")
extern int pg_mblen(const char *mbstr);

That'd avoid accidental reintroduction, and also get extension
maintainers' attention. $SUBJECT is C23/C++14's syntax, but you've
long been able to do that with in __attribute__ or __declspec for the
usual suspects so I looked into which compiler versions introduced
that and came up with the attached.

Yes, this makes sense. There have been discussions about a deprecated
attribute before (such as [0]/messages/by-id/d80b6adf-4bfd-4172-a9cd-2ad6e23b1a08@eisentraut.org), but in those cases it was mostly about
nagging people about coding style, which had potentially annoying
effects for extension authors that want to cover many major versions.
But in this case, we are actively encouraging people to get rid of a
function use, so it seems like a very suitable use case.

[0]: /messages/by-id/d80b6adf-4bfd-4172-a9cd-2ad6e23b1a08@eisentraut.org
/messages/by-id/d80b6adf-4bfd-4172-a9cd-2ad6e23b1a08@eisentraut.org

The idea would be to back-patch the deprecation warnings, and delete
the functions in, I guess now, v20. Then the deprecation notice
facility would always be there for next time we need it.

It might be enough to put the deprecation attribute into PG19. That
way, extension authors will see it (unless the extension is not
supporting PG19, in which case it seems likely that they also won't
bother to make any adjustments to avoid deprecated functions).

This piece

+#elif defined(__clang__) || (defined(__GNUC__) && __GNUC__ >= 5)
+#define pg_attribute_deprecated(message) 
__attribute__((deprecated(message)))

could be written as

#elif __has_attribute(deprecated)
...

__has_attribute works back to PG14.

If you do want to backpatch it, I would skip the C23/C++ branch for
versions PG18 and older. That way, each branch has an internally
consistent handling of attributes. (We have some C23/C++ attributes in
PG19, but not before.)

Bertrand Drouvot

bertranddrouvot.pg@gmail.com

5 days ago

In reply to: Michael Paquier (#2)

Re: [[deprecated("don't call this, call that")]]

Hi,

On Thu, Apr 09, 2026 at 12:42:36PM +0900, Michael Paquier wrote:

On Thu, Apr 09, 2026 at 03:34:30PM +1200, Thomas Munro wrote:

The idea would be to back-patch the deprecation warnings, and delete
the functions in, I guess now, v20. Then the deprecation notice
facility would always be there for next time we need it.

That would be a nice addition, especially with the recent mblen()
business (could have used that a few times myself). So +1 for the
addition of the macro in the back branches.

Do we need to be that conservative with the removal in v19? We could
just pull the deletion switch without waiting for v20, IMO.. With the
deprecated macro in place, at least folks would be aware of the
problem.

+1 on the idea. FWIW it has also been proposed in [1]/messages/by-id/aRGa87Ab0f3ItWRV@ip-10-97-1-34.eu-west-3.compute.internal. Also good candidates are
XLogRecPtrIsInvalid() and StaticAssertStmt(). Note that a recent commit made
use of StaticAssertStmt(), see [2]/messages/by-id/adeNWH5pDawDvvR2@ip-10-97-1-34.eu-west-3.compute.internal.

[1]: /messages/by-id/aRGa87Ab0f3ItWRV@ip-10-97-1-34.eu-west-3.compute.internal
[2]: /messages/by-id/adeNWH5pDawDvvR2@ip-10-97-1-34.eu-west-3.compute.internal

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

[[deprecated("don't call this, call that")]]

Attachments: