column type/typmod for domains in backend protocol

Tom Lane wrote:
Re: [ODBC] using domain types with ODBC, esp. lo

>Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de> writes:
>
>
>In my schema definitions, I usually don't use basic datatypes, but self
>defined domains. This seems to work in general, but I encountered
>problems with blobs.
>
>I'm using CREATE DOMAIN t_image AS lo;
>
>While inserting data isn't sensitive to domains, selecting won't work.
>The reason is that the row's datatype obtained with CI_read_fields is
>compared to lo's oid. t_image's oid is different, so the column is
>handled wrong..
>
>
>
>>Actually, best thing for this problems would be if the backend would
>>deliver the base type oid, not the user type oid.
>>
>>
>
>There was some discussion of that idea in pgsql-hackers last week, but
>we didn't come to a definite conclusion. How do others feel about it?
>
> regards, tom lane
>
>
>
Tom,

is there any more conversation or decision about this I missed? I
couldn't find a thread about this topic in pgsql-hackers.
I don't think that anybody would notice a degradation of correctness of
the drivers if the backend delivered the base type instead of the domain
type id. The handling procedures are completely specified by the base
type and additional fields delivered (atttypmod/typmod), and so no more
distinction at that level should be necessary. Tools dealing with
non-basic types will certainly use direct access to pg_type etc on top
of a query interface instead of dealing with the low level protocol.
Reading up and down the Roadmap FE/BE protocol thread, I understand that
only basic information should be delivered automatically, not extended.
I consider a domain oid as extended, while basic information is what's
needed to interpret the data correctly.

If the protocol stays at it is, I'd have to implement some kind of type
cache in a custom odbc driver version, which is certainly quite a poor
way. At the moment, the odbc driver simply won't get the information it
needs.

Regards,
Andreas