On Dec 18, 2007 11:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Chernow <[EMAIL PROTECTED]> writes:
> > When dealing with binary, the Oid the client sends may match what the
> > server thinks but the data is wrong (client sent binary formatted data
> > of the wrong type). Thus, the only real check we saw was on the data
> > length (which is rolling the dice).
>
> Yes, the available checks to detect client-vs-server datatype mismatch
> are very weak, but that hardly comes across as a good argument for
> removing one of the ones we have.
We are not suggesting to remove the check...but only to disable it
when the client explicitly asks the server. Right now, the checking
on composites is actually much stricter than on regular query
parameters. This strictness forces the client to 'know' the oid of
every field inside the composite.
> > How is the client supposed to send back composite types without having a
> > meaningful way to get the Oids from the server?
>
> On what grounds do you claim that it can't get the type Oids from the
> server?
Well, it's certainly possible, but awkward. The client has to
directly query the system catalogs. This has problems....there are
invalidation issues (which our idea does not address) and the user is
not guaranteed to have permission to access the proper catalogs. If
we go this route, IMO there should be a API function to expose this
behavior.
With the above issues, it seems that it would be nicer not to expose
Oids to the client at all but instead do parameter binding directly on
typename. ISTM this is not possible though.
merlin & andrew
eSilo
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
