Re: Arrays of domain returned to client as non-builtin oid describing the array, not the base array type's oid

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: James Robinson <james(at)jlr-photo(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Arrays of domain returned to client as non-builtin oid describing the array, not the base array type's oid
Date: 2019-01-04 19:24:15
Message-ID: 201901041924.hu6jvjqfdp46@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-01-04 19:35:51 Re: Use atexit() in initdb and pg_basebackup
Previous Message Peter Geoghegan 2019-01-04 18:42:15 Re: Making all nbtree entries unique by having heap TIDs participate in comparisons