Re: Why don't we support external input/output functions for the composite types

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why don't we support external input/output functions for the composite types
Дата
Msg-id 3833077.1714020280@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Why don't we support external input/output functions for the composite types  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Why don't we support external input/output functions for the composite types  (Dilip Kumar <dilipbalaut@gmail.com>)
Re: Why don't we support external input/output functions for the composite types  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Dilip Kumar <dilipbalaut@gmail.com> writes:
> I'm curious about composite types in PostgreSQL. By default, when we
> create a composite type, it utilizes the "record_in" and "record_out"
> functions for input/output. Do you think it would be beneficial to
> expand the syntax to allow users to specify custom input/output
> functions when creating composite types?

No.

> I believe it would be beneficial because users creating a new type
> might prefer to define specific input/output syntax rather than
> conforming to what is accepted by the RECORD type.

The primary outcome would be to require a huge amount of new work
to be done by a lot of software, much of it not under our control.
And the impact wouldn't only be to software that would prefer not
to know about this.  For example, how likely do you think it is
that these hypothetical user-defined I/O functions would cope
well with ALTER TABLE/ALTER TYPE commands that change those
rowtypes?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: AIX support