Re: Arrays of domain returned to client as non-builtin oiddescribing the array, not the base array type's oid - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Arrays of domain returned to client as non-builtin oiddescribing the array, not the base array type's oid
Date
Msg-id 201901041924.hu6jvjqfdp46@alvherre.pgsql
Whole thread Raw
In response to Arrays of domain returned to client as non-builtin oid describing thearray, not the base array type's oid  (James Robinson <james@jlr-photo.com>)
Responses Re: Arrays of domain returned to client as non-builtin oid describing the array, not the base array type's oid  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2019-Jan-02, James Robinson wrote:

> So -- do others find this inconsistent, or is it just me and I should
> work on having psycopg2 be able to learn the type mapping itself if I
> don't want to do SQL-side casts? I'll argue that if scalar projections
> erase the domain's oid, then array projections ought to as well.

Sounds reasonable.

Do you have a link to a previous discussion that rejected changing the
returned OID to that of the domain array?  I want to know what the argument
is, other than backwards compatibility.

Disregarding the size/shape of a patch to change this, I wonder what's
the cost of the change.  I mean, how many clients are going to be broken
if we change it?  And by contrast, how many apps are going to work
better with array-on-domain if we change it?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
Next
From: Alvaro Herrera
Date:
Subject: Re: Use atexit() in initdb and pg_basebackup