On Monday, October 28, 2002, at 07:57 PM, Rudy Lippan wrote:
The extra quotes are a result of passing quoted data to execute(), notsingle-quotes shouldn't be double-escaped in either strings or binary strings. Only null characters and backslashes should be double-escaped.
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.
Agreed.
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.
Agreed. I've avoided using boolean data types for this very reason.
thirdly, array column types are wholly unsupported (Yes PostgreSQL supportsYeah. I'd love to see array columns converted to and from Perl arrays, actually. That'd be *way* cool.
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.
Okay. I can handle that patch.
Huh? I thought that DBD::Pg just calls PQftype on each column of theYes, that's what it does. This might work with prepared statements (Bruce?), but you're right, it won't work if a statement hasn't been executed yet.
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.
I looked at the new PREPARE statement, and it looks like it might takeHrm. What you're talking about is out of my league, I'm afraid. Hopefully I'll have a chance to look at this stuff myself in the not-to-distant future.
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.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
