Possibilities on code change to implement pseudodatatypes - Mailing list pgsql-hackers

From Vinícius Abrahão
Subject Possibilities on code change to implement pseudodatatypes
Date
Msg-id CAM9Bftxea3LROPWcx4FzvRQEN_4Yn-wOfqL+goGVpjK5bhxt_g@mail.gmail.com
Whole thread Raw
Responses Re: Possibilities on code change to implement pseudodatatypes
List pgsql-hackers
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.

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Pgoutput not capturing the generated columns
Next
From: Tatsuo Ishii
Date:
Subject: Re: Doc: typo in config.sgml