Hi Chapman & Pavel
On 25.01.25 16:05, Pavel Stehule wrote:
>
>
> so 25. 1. 2025 v 15:10 odesílatel Chapman Flack <jcflack@acm.org> napsal:
>
> On 01/25/25 02:16, Pavel Stehule wrote:
> > because the function does nothing, then it is useless to convert
> input to
> > XML and force detosting
> >
> > Maybe the body of the function should be just
> > ...
> > PG_RETURN_DATUM(PG_GETARG_DATUM(0));
>
> That sort of motivated my question upthread about whether there is
> already a function somewhere in the codebase that does exactly that
> and could be named in the pg_proc entry for xmldocument, as an
> alternative to supplying a brand-new one.
>
>
> this should not be a problem, because the already created function
> XMLDOCUMENT surely will not be in the pg_catalog schema.
>
>
>
> Maybe this is the only instance where it turns out that 'identity'
> is the right behavior for a function. But if it could conceivably
> happen again, a single C function (maybe even named identity) could
> reduce code duplication and make quite clear what the behavior is
> with a \sf.
>
>
> I didn't find any function like this.
I also couldn't find any similar function.
>
> Regards
>
> Pavel
>
>
> A generic 'identity' function would be lacking the #ifdef USE_LIBXML
> and the error message, but I'm not convinced those matter here
> anyway. Without XML support, you'll already have raised that error
> in any attempt to construct a non-null XML argument to pass, and if
> you're passing NULL and the function is strict, you'll never see
> the error message from here anyway.
>
>
Do you envision something like this?
Datum
identity(PG_FUNCTION_ARGS)
{
PG_RETURN_DATUM(PG_GETARG_DATUM(0));
}
If so, where would be the right place to put it? Certainly not in xml.c
Generally speaking, reducing redundancy by reusing existing functions is
always a good thing. However, if we decide to create a generic function
for this purpose, it's important to ensure its existence is clearly
communicated to prevent others from writing their own -- something that,
given the simplicity of this function, seems like a likely scenario. :)
My point is: this function is so small that I’m not entirely sure it’s
worth the effort to make it generic. But I'd be willing to give it a try
if we agree on it.
Thanks!
Best regards, Jim
