Horton
Menu

Thread

  1. Possibilities on code change to implement pseudodatatypes

    Vinícius Abrahão <vinnix.bsd@gmail.com> — 2024-09-30T08:01:37Z

    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.

  2. Re: Possibilities on code change to implement pseudodatatypes

    Vinícius Abrahão <vinnix.bsd@gmail.com> — 2024-09-30T09:19:04Z

    On Mon, Sep 30, 2024 at 9:01 AM Vinícius Abrahão <vinnix.bsd@gmail.com>
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.

  3. Re: Possibilities on code change to implement pseudodatatypes

    Vinícius Abrahão <vinnix.bsd@gmail.com> — 2024-10-03T11:21:37Z

    On Mon, Sep 30, 2024 at 10:19 AM Vinícius Abrahão <vinnix.bsd@gmail.com>
wrote:

> On Mon, Sep 30, 2024 at 9:01 AM Vinícius Abrahão <vinnix.bsd@gmail.com>
> 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.
>

I see now how to workaround it based on the parameter below. However, it's
expected this will never work for a regular user/role.

postgres=# set allow_system_table_mods to on;
SET
Time: 5.190 ms
postgres=# create table a(a anyarray) ;
CREATE TABLE
Time: 132.959 ms

This is verified at heap_create_with_catalog(...) function.


Cheers,

--
vinnix
aka: Vinícius Abrahão Bazana Schmidt
twitter.com/vischmidt
linkedin.com/in/vischmidt