Re: Get TupleDesc for extension-defined types - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Get TupleDesc for extension-defined types
Date
Msg-id CAFj8pRBmNRedLQ=XuTd3MuMZh1eW19SY=HqzCQdXc8LYjGF+nQ@mail.gmail.com
Whole thread Raw
In response to Re: Get TupleDesc for extension-defined types  (Florents Tselai <florents.tselai@gmail.com>)
List pgsql-hackers


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


On Wed, Sep 18, 2024 at 1:09 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hi

st 18. 9. 2024 v 9:04 odesílatel Florents Tselai <florents.tselai@gmail.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


pgsql-hackers by date:

Previous
From: Florents Tselai
Date:
Subject: Re: Get TupleDesc for extension-defined types
Next
From: jian he
Date:
Subject: Re: attndims, typndims still not enforced, but make the value within a sane threshold