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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Why don't we support external input/output functions for the composite types
Date: 2024-04-25 04:44:40
Message-ID: 3833077.1714020280@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dilip Kumar <dilipbalaut(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-04-25 04:45:13 Re: AIX support
Previous Message Masahiko Sawada 2024-04-25 04:38:28 Re: [PoC] Improve dead tuple storage for lazy vacuum