From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Cc: | david(at)justatheory(dot)com |
Subject: | domain constraints and UNKNOWN params |
Date: | 2006-01-12 00:30:01 |
Message-ID: | 1137025801.9143.113.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
David Wheeler reported the following bug: when a protocol-level prepared
statement with a parameter of UNKNOWN type is used, any domain
constraints that are associated with the inferred type of the parameter
are not checked when the statement is executed. Attached is a script
David sent me to reproduce the problem: when pg_server_prepare is
enabled (the default), DBD::Pg uses protocol-level prepared statements,
and the script is able to insert a tuple that violates the domain's
check constraint. Disabling pg_server_prepare results in a constraint
failure, as it should.
I've also attached a patch that should fix the issue -- coerce_type()
neglected to apply coerce_to_domain() to the type inferred for an
UNKNOWN Param. Barring any objections, I intend to apply the patch to
HEAD and release branches as far back as the problem exists (likely 8.0
and 8.1, and possibly 7.4 -- I haven't checked yet).
It would be nice to add regression tests for this issue, but AFAICS
there's no way to specify parameters of UNKNOWN type to a prepared
statement created via SQL -- which might be worth implementing anyway...
-Neil
Attachment | Content-Type | Size |
---|---|---|
test.pl | application/x-perl | 663 bytes |
unknown_prep_stmt_domain-1.patch | text/x-patch | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-12 04:31:16 | Re: domain constraints and UNKNOWN params |
Previous Message | Scott Marlowe | 2006-01-11 23:31:23 | Re: Different exponent in error messages |