On Sat, 26 Oct 2002, David Wheeler wrote: > But the real solution is the one Rudy suggested. The appearance of the > single quotes around data escaped by quote() is there because the > method is designed for quoting data you wish to use inline in a SQL > statement, not with placeholders. Thus, it's designed for something > like this:
I had an email writtin up WRT this, but I did not sent it because I wanted to test something out, and never got around to writing the test on friday. I assumed that he was passing quoted data to execute; however, when I thought about it, there should have been more of a diff. between the two than just a leading and trailing quote, because the quote() would have doubled up any internal "'"s or \'s (and if bound as SQL_BINARY, would quadruple the \'s up). My Guess it was that the since the bin col needed \\\\, that quote() escaped the the data, and the eacaping (in non-binary mode) in execute escaped the escaped the \, so that it inserted correctly (save for for the doubling of the quotes). > Now, the driver-development questions: Should DBD::Pg's execute() > method know which bound parameters are binary without being explicitly > told via the attributes to bind_param(), and escape accordingly? Or > should DBI users always explicitly bind binary data using > bind_param()'s attributes? How do you plan for DBD::Pg to know? Unless libpq will give you the data you need to make this decision, I don't see this as an option. > If the answer to the first question is "yes", then how should this be > implemented? And if the answer to the first question is "no" and the How *should* it be implemented: How about a libpq() prepare function that would parse the statement, store the execution plan, and return a list of column types to the DBD::Pg so that when execute was called DBD::Pg would know how to bind the columns. I have not been folowing the PostgreSQL mailing lists, so I do not know know if a prepare() is ever going to be. > second question is "maybe", would it make sense to have whatever code > in execute() that is escaping string data also do the proper escapes > for binary data, since in PostgreSQL they're compatible? If you use the same escapes for string data as you use for binary data, will you not have to worry about the quadrupling of the \'s within the strings ? -r
