| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Subject: | Re: CURL_IGNORE_DEPRECATION |
| Date: | 2025-11-11 13:14:01 |
| Message-ID: | e8ffd6aa-210d-4057-a104-ae48d5c217a1@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2025-11-11 Tu 6:41 AM, Álvaro Herrera wrote:
> Hackers,
>
> I just noticed that we have some ad-hoc hacks for the
> CURL_IGNORE_DEPRECATION macro in the pgindent Perl script, which I find
> a bit uncomfortable. Given that we use that macro in a single place,
> what do you think about removing that and making a more surgical
> intervention to fix pgindent problem with it? I propose the attached.
>
> For context: in curl, that macro is defined like this
>
> #define CURL_IGNORE_DEPRECATION(statements) \
> _Pragma("GCC diagnostic push") \
> _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"") \
> statements \
> _Pragma("GCC diagnostic pop")
>
> (with #ifdef guards and whatnot). Because it has a _Pragma after the
> statements argument, any uses of this macro must have a terminating
> semicolon, which pgindent does not like. (It's also IMO rather
> C-unlike). So my approach here is to add another macro to insert that
> semicolon where it's needed. Of course, there's nothing we can do with
> CURL_IGNORE_DEPRECATION() itself, given that it's upstream from us.
>
> Thoughts?
>
Looks reasonable. The regex in pgindent is fairly impenetrable, so
getting rid of it would be nice.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2025-11-11 13:22:14 | Re: pgsql: Drop unnamed portal immediately after execution to completion |
| Previous Message | Matheus Alcantara | 2025-11-11 12:47:02 | Re: Include extension path on pg_available_extensions |