Re: Get TupleDesc for extension-defined types

st 18. 9. 2024 v 16:25 odesílatel Florents Tselai <florents(dot)tselai(at)gmail(dot)com>
napsal:

>
>
> On Wed, Sep 18, 2024 at 1:09 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>> Hi
>>
>> st 18. 9. 2024 v 9:04 odesílatel Florents Tselai <
>> florents(dot)tselai(at)gmail(dot)com> napsal:
>>
>>> Correct me if I'm wrong,
>>> but for an extension that defines composite types,
>>> there's currently no easy way to get a TupleDesc, even for its own types.
>>>
>>> Something like
>>> TupleDesc get_extension_type_tupledesc(const char *extname, const char
>>> *typname)
>>>
>>> Here's a routine I've stolen borrowed from pramsey's code and have been
>>> using ever since.
>>>
>>> Could this be exposed in extension.h ? (probably without the version
>>> check)
>>>
>>
>> I don't think this functionality is generally useful. Wrapping
>> TypeGetTupleDesc(typoid, NIL) is very specific, and probably this code
>> should be inside the extension.
>>
>> Different question is API for searching in system catalog and
>> dependencies. I can imagine some functions like
>>
>
> That's a better phrasing
>
>>
>> Oid extid = get_extension_id(extname);
>> Oid objid = get_extension_object_id(extid, schema_can_be_null, name,
>> TYPEOID); // can be used for routine, table, ...
>>
>> tupdesc = TypeGetTupleDesc(objid, NIL);
>>
>
> These are valid.
> For context:
> The "problem" (inconvenience really) I'm trying to solve is this:
> Most extensions define some convenient PG_GETARG_MYTYPE(n) macros.
> When these types are varlena, things are easy.
>
> When they're composite types though things get more verbose.
> i.e. the lines of code the author needs to get from a Datum argument to
> struct MyType are too many
> and multiple extensions copy-paste the same logic.
>
> My hope is we could come up with a few routines that ease and standardize
> this a bit.
>
> You're right that extname isn't unique, so Oid should be the argument for
> extension, rather than char *extname,
> but in my mind the "default" is "the current extension" , but no arguing
> about that.
>

what you mean "the current extension" - there is nothing like this. The
functions have not any information without searching in the catalog about
their extension. Function knows just its own oid and arguments. I can
imagine so fmgr can be enhanced by it - it can reduce some searching, but
currently there is nothing like current or owner extension (extension id).

>> Regards
>>
>> Pavel
>>
>>
>>