Re: Records, Types, and Arrays - Mailing list pgsql-general

From Raymond Brinzer
Subject Re: Records, Types, and Arrays
Date
Msg-id CANasJH=Ypp+3OtEHsbLGe1kmh5DV4Ez+o8ABApNy5Vkh96zJeA@mail.gmail.com
Whole thread Raw
In response to Re: Records, Types, and Arrays  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-general


On Fri, May 19, 2023 at 2:58 AM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Thursday, May 18, 2023, Raymond Brinzer <ray.brinzer@gmail.com> wrote:
scratch=# select row(2,3)::test_type;

Unknown typed value, immediately converted to a known concrete instance of test_type. It is never actually resolved as record.

All of the others must concretely be resolved to record to escape their query level, and if you then try to cast the concrete record to some other concrete type a cast needs to exist.

I see.  That suggests, oddly, that pg_typeof() is changing the thing it's observing, because row(2,3) was not a record but an 'unknown typed value' before pg_typeof() was called on it.  Good to know.

CREATE CAST seems not to like working with pseudo-types.  Neither the source nor the target can be 'anyarray' or 'record'.  So that seems out.

On the other hand, the pseudo-type doc says, 'Functions coded in C (whether built-in or dynamically loaded) can be declared to accept or return any of these pseudo data types.'  I'm assuming that an 'unknown typed value" corresponds to the 'unknown' pseudo-type.  So it seems like a C function which took an anyarray as its parameter, and returned a value of type 'unknown' would bypass the need for a specifically defined cast.  (Emphasis on "seems".)
--
Ray Brinzer

pgsql-general by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Records, Types, and Arrays
Next
From: FOUTE K. Jaurès
Date:
Subject: Re: PostgreSQL 13 - Logical Replication - ERROR: could not receive data from WAL stream: SSL SYSCALL error: EOF detected