From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SPI refactoring |
Date: | 2019-11-08 12:50:13 |
Message-ID: | 20191108125013.GA26112@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-Nov-07, Mark Dilger wrote:
> From 113d42772be2c2abd71fd142cde9240522f143d7 Mon Sep 17 00:00:00 2001
> From: Mark Dilger <hornschnorter(at)gmail(dot)com>
> Date: Thu, 7 Nov 2019 07:51:06 -0800
> Subject: [PATCH v1 1/5] Deprecating unused SPI error codes.
>
> The SPI_ERROR_NOOUTFUNC and SPI_ERROR_CONNECT codes, defined in spi.h,
> were no longer used anywhere in the sources except nominally in spi.c
> where SPI_result_code_string(int code) was translating them to a cstring
> for use in error messages. But since the system never returns these
> error codes, it seems unlikely anybody still needs to be able to convert
> them to a string.
>
> Removing these from spi.c, from the docs, and from a code comment in
> contrib. Leaving the definition in spi.h for backwards compatibility of
> third-party applications.
Because of PG_MODULE_MAGIC forcing a recompile of modules for each major
server version, there's no ABI-stability requirement for these values.
If we were to leave the definitions in spi.h and remove the code that
handles them, then code could compile but at run-time it would produce
the "unrecognized" string. Therefore I think it is better to remove the
definitions from spi.h, so that we can be sure that the code will never
be needed.
I didn't look at the other patches, but I suppose the same argument
applies to retaining their defines too.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2019-11-08 12:57:13 | Re: [Proposal] Global temporary tables |
Previous Message | Konstantin Knizhnik | 2019-11-08 12:43:12 | Re: Global temporary tables |