On Tue, Oct 29, 2002 at 07:12:39PM -0500, Rudy Lippan wrote:
> On Tue, 29 Oct 2002, Tim Bunce wrote:
>
> > That seems like a rather poor design.
> >
>
> I take it you have worked with PostgreSQL much :)
>
>
> > Beware that your semantics for SQL_BINARY must match those of ODBC.
> > I think ODBC requires SQL_BINARY values to be formated as pairs of
> > hex chars.
>
> So you are saying that when execute is called on a column that is bound as
> SQL_BINARY it should expect a string of hex digits? something like,
> execute("fffcfdfa010c")? Then all execute need do is slap a X''
> around the string before submitting to the db (or in PGs case converting
> everything to octal escapes).
Yes.
> Do you have a reference for the ODBC spec that you could point me to?
There are some URLs in the DBI docs, along with details of how to search
microsoft.com for more info.
> If it be the case that the values submitted to execute() are required to
> be in the form of 'deadbeef', then the current behavour of execute() is
> broken and has been broken since DBD::Pg .98(?).
Would only need to be in the form of 'deadbeef' when the value is
typed as SQL_BINARY.
> How would you suggest
> handling this, a) Call it a bug, deprecate the usage of SQL_BINARY with
> binary data in the next version, and then fix it in the version after?
> b) leave it as is c) just fix it and say that the next version is not
> compatible with earlier versions of DBD::Pg wrt binding as SQL_BINARY d)
> something else.
I wasn't aware that DBD::Pg supported using SQL_BINARY with bind_param.
The docs at http://search.cpan.org/author/JBAKER/DBD-Pg-1.13/Pg.pm don't
mention it. If it's a recent change then (c) may be best. Else (a) or (b)
depending on how much code may be 'out there' using it. Since few drivers
support SQL_BINARY it's not critical which option you take.
The most important thing is to get to a point where you can bind
any value to a placeholder and have it 'just work' without the
application having to do anything 'odd' to the value (like reformat
it as hex chars).
Tim.
