pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedusing domain types with ODBC, esp. lo
3+ messages / 2 participants
[nested] [flat]
* using domain types with ODBC, esp. lo
@ 2003-03-21 16:19 Andreas Pflug <Andreas.Pflug@web.de>
0 siblings, 1 reply; 3+ messages in thread
From: Andreas Pflug @ 2003-03-21 16:19 UTC (permalink / raw)
To: pgsql-odbc@postgresql.org
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. This means, that at the moment domains are not usable on
lo columns with ODBC.
As a workaround, the driver could maintain an internal list of domain's
oids, mapping them to lo's oid when CI_read_fields detects one.
There might be another flaw inside CI_read_fields.
The well-known data types PG_TYPE_DATETIME, PG_TYPE_TIMESTAMP_NO_TMZONE,
PG_TYPE_TIME, PT_TYPE_TIME_WITH_TMZONE are handled in a special way
concerning the atttypmod field. This will fail for domain types of that
base type.
Actually, best thing for this problems would be if the backend would
deliver the base type oid, not the user type oid.
And lo could be hard-coded to the backend too... :-)
Regards,
Andreas
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: using domain types with ODBC, esp. lo
@ 2003-03-21 16:31 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andreas Pflug <Andreas.Pflug@web.de>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2003-03-21 16:31 UTC (permalink / raw)
To: Andreas Pflug <Andreas.Pflug@web.de>; +Cc: pgsql-odbc@postgresql.org
Andreas Pflug <Andreas.Pflug@web.de> writes:
> The well-known data types PG_TYPE_DATETIME, PG_TYPE_TIMESTAMP_NO_TMZONE,
> PG_TYPE_TIME, PT_TYPE_TIME_WITH_TMZONE are handled in a special way
> concerning the atttypmod field. This will fail for domain types of that
> base type.
This is correct, since the domain won't expose the atttypmod it assigns
to the underlying type.
> 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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: using domain types with ODBC, esp. lo
@ 2003-03-21 16:48 Andreas Pflug <Andreas.Pflug@web.de>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Andreas Pflug @ 2003-03-21 16:48 UTC (permalink / raw)
To: pgsql-odbc@postgresql.org
>
>
>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
>
>
I think there a several ways:
- base type OID instead of user type OID. Might break some clients
dealing with special types. ODBC users won't notice.
- a postgresql.conf option to tell the backend to use base type OID or
user type OID. Would catch most cases.
- a connection specific setting to tell the backend to use base type OID
or user type OID. For concurrent ODBC and weird clients use.
- base type additionally in the RowDescription message. Obviously, this
would break the 7.3 protocol.
Regards,
Andreas
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2003-03-21 16:48 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-03-21 16:19 using domain types with ODBC, esp. lo Andreas Pflug <Andreas.Pflug@web.de>
2003-03-21 16:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-03-21 16:48 ` Andreas Pflug <Andreas.Pflug@web.de>
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