On Thursday, May 1, 2025, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>
> In light of these concerns, I've been contemplating alternative
> interface designs. One promising approach would involve registering
> custom copy formats via a C function during module loading
> (specifically, in _PG_init()). This method would require extension
> authors to invoke a registration function, say
> RegisterCustomCopyFormat(), in _PG_init() as follows:
>
> JsonLinesFormatId = RegisterCustomCopyFormat("jsonlines",
> &JsonLinesCopyToRoutine,
> &JsonLinesCopyFromRoutine);
>
> The registration function would validate the format name and store it
> in TopMemoryContext. It would then return a unique identifier that can
> be used subsequently to reference the custom copy format extension.
>
How does this fix the search_path concern? Are query writers supposed to
put JsonLinesFormatId into their queries? Or are you just prohibiting a
DBA from ever installing an extension that wants to register a format name
that is already registered so that no namespace is ever required?
ISTM accommodating a namespace for formats is required just like we do for
virtually every other named object in the system. At least, if we want to
play nice with extension authors. It doesn’t have to be within the
existing pg_proc scope, we can create a new scope if desired, but
abolishing it seems unwise.
It would be more consistent with established policy if we didn’t make
exceptions for text/csv/binary - if the DBA permits a text format to exist
in a different schema and that schema appears first in the search_path,
unqualified references to text would resolve to the non-core handler. We
already protect ourselves with safe search_paths. This is really no
different than if someone wanted to implement a now() function and people
are putting pg_catalog from of existing usage. It’s the DBAs problem, not
ours.
David J.
