-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> So again, I'd like to hear any comments about my pattern-matching
> proposal. Is there any problem here that it would not solve?
> Does anyone see a problem in implementing them?
Quoting. Extra parsing work.
Specifically, your proposal (if I read it correctly) would require me
to send in the full SQL statement every time, thus negating a major
benefit of prepared statements in that I do not have to quote the
values myself, but can let the server handle it. It would also be a lot
of work for the server to parse the statement and find a "match".
Maybe enough work to make the "solution" worse than the cure.
If, on the other hand, you are suggesting sending the statement and
parameters separately, that would be slightly better, but (like above)
it would be quite a bit of extra traffic to send the whole query and
variables for every single execute.
Finally, I am still not convinced there is a problem at all. While the
current behavior is a bit quirky, I think it does work out overall.
A prepared statement will throw an error on two conditions:
1) The name is already in use.
This is trivial to solve by the client, so it should never arise.
(with the caveat that middleware should clearly document its naming
scheme, and request and/or enforce that the client not creating
conflicting names). So we really should remove this from the debate.
2) The statement is invalid.
This one is very common, and it /should/ throw an error. With the fact
that statements cannot be shared across connections, and the handy
PQtransactionStatus function, the client should easily be able to
handle any situation that arises smoothly.
Having the statement exist even on rollback is a little harder to
accept, but I have yet to see a better alternative. Prepare statements
already "break the rules" anyway, by the fact that a commit() after a
prepare does not make them available to any other people viewing
the database.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200407021729
-----BEGIN PGP SIGNATURE-----
iD8DBQFA5dlnvJuQZxSWSsgRApVZAKDl4JznBEf/PBZ8NxBPZf7GdapFsACfc4ro
sIoFwz9mdSxpRvET2WgQHog=
=pIFV
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
