public inbox for [email protected]
help / color / mirror / Atom feedFrom: Vinícius Abrahão <[email protected]>
To: [email protected]
Subject: Re: Possibilities on code change to implement pseudodatatypes
Date: Mon, 30 Sep 2024 10:19:04 +0100
Message-ID: <CAM9Bftxj4MsTb=mhOa7hnv0ZSRJg7fidEwUxT8RS-ejAio+iSQ@mail.gmail.com> (raw)
In-Reply-To: <CAM9Bftxea3LROPWcx4FzvRQEN_4Yn-wOfqL+goGVpjK5bhxt_g@mail.gmail.com>
References: <CAM9Bftxea3LROPWcx4FzvRQEN_4Yn-wOfqL+goGVpjK5bhxt_g@mail.gmail.com>
On Mon, Sep 30, 2024 at 9:01 AM Vinícius Abrahão <[email protected]>
wrote:
> Greetings
>
> I understand the complexity of implementing a pseudo data type when
> passing it over parameters, or using it when creating an object.
> vide: git grep pseudo | egrep -v -e "po|out|sgml|sql" | more
>
> My initial problem was saving history (for backup to be used during
> troubleshoot analysis) of plan changing and so on.. of the pg_statistic
> table/object.
>
> I was surprised - in a good way - to observe so much effort when handling
> it for that specific purpose. I started to wonder if/when I want to create
> an object of other *pseudatatypes *or pass it through a function
> parameter that the same level of effort during code implementation would be
> the same.
>
> I understand this would be much more a code architecture discretion rather
> than a punctual question.
>
> I have posted in pgsql-admin a question which is "simple problem" when
> creating a table using anyarray and indeed the problem is simple - the
> solution might not be.
>
> What folks, more experienced in this subject, would recommend as a
> starting point to achieve that objective?
>
> Kind regards,
>
> Bazana Schmidt, Vinícius
>
> PS.: apologize in advance for the HTML email.
>
Complementing -
Under this optics below:
[vinnix@vesuvio postgres]$ git grep CheckAttributeType
src/backend/catalog/heap.c: * flags controls which datatypes are
allowed, cf CheckAttributeType.
src/backend/catalog/heap.c:
CheckAttributeType(NameStr(TupleDescAttr(tupdesc, i)->attname),
src/backend/catalog/heap.c: * CheckAttributeType
src/backend/catalog/heap.c:CheckAttributeType(const char *attname,
src/backend/catalog/heap.c: CheckAttributeType(attname,
getBaseType(atttypid), attcollation,
src/backend/catalog/heap.c:
CheckAttributeType(NameStr(attr->attname),
src/backend/catalog/heap.c: CheckAttributeType(attname,
get_range_subtype(atttypid),
src/backend/catalog/heap.c: CheckAttributeType(attname,
att_typelem, attcollation,
src/backend/catalog/index.c:
CheckAttributeType(NameStr(to->attname),
src/backend/commands/tablecmds.c:
CheckAttributeType(NameStr(attribute->attname), attribute->atttypid,
attribute->attcollation,
src/backend/commands/tablecmds.c: CheckAttributeType(colName,
targettype, targetcollid,
src/backend/commands/tablecmds.c:
CheckAttributeType(partattname,
src/include/catalog/heap.h:/* flag bits for
CheckAttributeType/CheckAttributeNamesTypes */
src/include/catalog/heap.h:extern void CheckAttributeType(const char
*attname,
and this line:
https://github.com/postgres/postgres/blob/master/src/backend/catalog/heap.c#L562
if (att_typtype == TYPTYPE_PSEUDO)
{
/*
* We disallow pseudo-type columns, with the exception of ANYARRAY," <<==
What WE are missing? WHY? How could we make this state true for creating
table commands?
I will try to find time to keep researching about it - if you folks have
any insights please let me know.
view thread (3+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected]
Subject: Re: Possibilities on code change to implement pseudodatatypes
In-Reply-To: <CAM9Bftxj4MsTb=mhOa7hnv0ZSRJg7fidEwUxT8RS-ejAio+iSQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox