On Mon, 28 Oct 2002, David Wheeler wrote: > Yes, that was my guess, too. But since ' shouldn't be double-escaped > with \\\\, I would say that quote() doesn't work with binary data. >
The extra quotes are a result of passing quoted data to execute(), not any problem with quote() itself; it just so happened that the data needed to be double quoted for bytea column type, so things worked save the 2 extra 's. I think we have are beating a dead horse here; we can take this off list if you want. I was thinking about how quote/execute should work in DBD::Pg. fist off the quote part of execute should be merged into a general quote method that will be called by quote() and execute(), for there is no need to duplicate the code. secondly, quote should be smart enough to turn 1||0 into TRUE/FALSE if the column be bound as boolean. Right now, when data are selected out of the DB, DBD::Pg converts 't'=>1 and 'f'=0, so you have a situation whereby you cannot insert the data that you just selected back into the db without munging it yourself. thirdly, array column types are wholly unsupported (Yes PostgreSQL supports columns as arrays, don't ask my why (I am nocent. I have used it on occasion)). What is the best way to handle array data ind DBI? At a very minimum DBD::Pg should probably provide a quote_array/unquote_array() to the application so that the app can work with the array data. and finally, binary data should be handled as it is now, with the exception of having quote() know what to do when passed SQL_BINARY. > > 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. > > We could use the introspection methods to do this. DBD::Pg already does > this for fetches. Huh? I thought that DBD::Pg just calls PQftype on each column of the result set to get the field type, so I don't see how this would apply to a query that has not been execute()ed yet? Am I missing something here (as usual)? What introspection methods are you talking about? I am confused. > Yes, this would rock -- especially if we added support for prepared > statements (a new feature in PostgreSQL 7.3, which is now in its third > beta release). > I looked at the new PREPARE statement, and it looks like it might take some hackery to get it to work seamlessly in DBD::Pg; The first problem I see would be the naming the queries (Today we have the naming of queries?). And then there is the backwards compatibility problem (and a rewrite of preparse and of execute). I'd have to play with PREPARE some more to see if it be worth doing. -r
