public inbox for [email protected]  

help / color / mirror / Atom feed

From: Peter Eisentraut <[email protected]>
To: Thomas Munro <[email protected]>
To: PostgreSQL Hackers <[email protected]>
Subject: Re: [[deprecated("don't call this, call that")]]
Date: Thu, 9 Apr 2026 12:42:52 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKGK2zuRevnNzCpVzLA7ieHnJoYPnDvgtWRcB4pVnOzchhQ@mail.gmail.com>
References: <CA+hUKGK2zuRevnNzCpVzLA7ieHnJoYPnDvgtWRcB4pVnOzchhQ@mail.gmail.com>

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]), 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]: 
https://www.postgresql.org/message-id/d80b6adf-4bfd-4172-a9cd-2ad6e23b1a08%40eisentraut.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.)

view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: [[deprecated("don't call this, call that")]]
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox