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

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> 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.

TBH I doubt it was ever discussed; I don't recall having thought about
doing that while working on c12d570fa.

> Disregarding the size/shape of a patch to change this, I wonder what's
> the cost of the change.

It could be kind of expensive. The only way to find out whether an array
is over a domain type is to drill down to the element type and see. Then
if it is, we'd have to drill down to the domain base type, after which we
could use its typarray field. So that means at least one additional
syscache lookup each time we determine which type OID to report.

I think there are also corner cases to worry about, in particular what
if the base type lacks a typarray entry? This would happen at least
for domains over arrays. We don't have arrays of arrays according to
the type system, but arrays of domains over arrays allow you to kind
of fake that. I don't see a way to report a valid description of the
data type while still abstracting out the domain in that case.

> I mean, how many clients are going to be broken
> if we change it?

This possibility only came in with v11, so probably there are few if any
use-cases of arrays-of-domains in the wild yet, and few or no clients
with intelligence about it. I don't think that backwards compatibility
would be a show-stopper argument against changing it, if we could satisfy
ourselves about the above points.

Having said that: in the end, the business of flattening scalar domains
was mainly meant to help simple clients handle simple cases simply.
I'm not sure that array cases fall into that category at all, so I'm
not that excited about adding complexity/cycles for this.

regards, tom lane