Possibilities on code change to implement pseudodatatypes
От | Vinícius Abrahão |
---|---|
Тема | Possibilities on code change to implement pseudodatatypes |
Дата | |
Msg-id | CAM9Bftxea3LROPWcx4FzvRQEN_4Yn-wOfqL+goGVpjK5bhxt_g@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Possibilities on code change to implement pseudodatatypes
|
Список | 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 по дате отправления: