pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedcolumn type/typmod for domains in backend protocol
2+ messages / 2 participants
[nested] [flat]
* column type/typmod for domains in backend protocol
@ 2003-04-09 12:02 Andreas Pflug <Andreas.Pflug@web.de>
0 siblings, 1 reply; 2+ messages in thread
From: Andreas Pflug @ 2003-04-09 12:02 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-interfaces
Tom Lane wrote:
Re: [ODBC] using domain types with ODBC, esp. lo
>Andreas Pflug <Andreas.Pflug@web.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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: column type/typmod for domains in backend protocol
@ 2003-04-09 15:06 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andreas Pflug <Andreas.Pflug@web.de>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2003-04-09 15:06 UTC (permalink / raw)
To: Andreas Pflug <Andreas.Pflug@web.de>; +Cc: pgsql-interfaces
Andreas Pflug <Andreas.Pflug@web.de> writes:
>>> Actually, best thing for this problems would be if the backend would
>>> deliver the base type oid, not the user type oid.
> is there any more conversation or decision about this I missed? I
> couldn't find a thread about this topic in pgsql-hackers.
AFAIR no one else has troubled to take a stand on the issue. I'll
follow your lead unless someone complains.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2003-04-09 15:06 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-04-09 12:02 column type/typmod for domains in backend protocol Andreas Pflug <Andreas.Pflug@web.de>
2003-04-09 15:06 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox