Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2020-Oct-26, Craig Ringer wrote:
>> also adds PQlibInfoPrint() which dumps PQlibInfo() keys/values to stdout.
> Sounds useful. I'd have PQlibInfoPrint(FILE *) instead, so you can pass
> stdout or whichever fd you want.
+1. Are we concerned about translatability of these strings? I think
I'd vote against, as it would complicate applications, but it's worth
thinking about it now not later.
>> Patch 0002 exposes LIBPQ_VERSION_STR, LIBPQ_VERSION_NUM and
>> LIBPQ_CONFIGURE_ARGS symbols in the dynamic symbol table. These can be
>> accessed by a debugger even when the library cannot be loaded or executed,
>> and unlike macros are available even in a stripped executable. So they can
>> be used to identify a libpq binary found in the wild. Their storage is
>> shared with PQlibInfo()'s static data, so they only cost three symbol table
>> entries.
> Interesting. Is this real-world useful?
-1, I think this is making way too many assumptions about the content
and format of a shlib.
>> Patch 0003 allows libpq.so to be executed directly from the command line to
>> print its version, configure arguments etc exactly as PQlibInfoPrint()
>> would output them. This is only enabled on x64 linux for now but can be
>> extended to other targets quite simply.
> +1 --- to me this is the bit that would be most useful, I expect.
Again, I'm not exactly excited about this. I do not one bit like
patches that assume that x64 linux is the universe, or at least
all of it that need be catered to. Reminds me of people who thought
Windows was the universe, not too many years ago.
I'd rather try to set this up so that some fairly standard tooling
like "strings" + "grep" can be used to pull out the info. Sure,
it would be less convenient, but honestly how often is this really
going to be necessary?
regards, tom lane
