bytea escape type 'hex' not being recognized about ruby-pg HOT 3 CLOSED

Original comment by Michael Granger (Bitbucket: ged, GitHub: ged).

No, the driver doesn't presume to know how to convert anything for you -- that's left to higher-level abstractions like Sequel, ActiveRecord, etc. The library returns pretty much exactly what the libpq library returns, with the notable exception of associating the Encoding (where possible) under Ruby 1.9.

However, there are two methods on the PGconn object to help you with doing the conversion yourself: [[http://deveiate.org/code/pg/PGconn.html#escape_bytea-instance_method|PGconn#escape_bytea]] and [[http://deveiate.org/code/pg/PGconn.html#unescape_bytea-instance_method|PGconn#unescape_bytea]].

There's more details about the design of the client library, including the topic of data type conversion, on [[http://wiki.postgresql.org/wiki/Driver_development|the PostreSQL wiki]].

Does that answer your questions?

from ruby-pg.

Original comment by Don Park (Bitbucket: donpdonp, GitHub: donpdonp).

The first guideline in the wiki is "Avoid Magic" or the principle of the least surprise. I believe that if I have a ruby string and store it with pg, the retrieved string should be identical. Do you agree?

if so, thats not happening. A rails app is storing an authentication string and getting a different string back so the app is breaking when postgres is using the 'new' binary escape mode (introduced in version 9), but works fine when the postgres 9 daemon is using the old escape mode.

from ruby-pg.

Original comment by Michael Granger (Bitbucket: ged, GitHub: ged).

My point was that the pg' library returns only what libpq' returns without modifications other than associating the encoding. This, to me, is avoiding "magic". The driver returns exactly what the client library returns from the database, without assuming that you'd want it converted to something else.

As with many cases when people cite the Principle of Least Surprise, it's dependent on whose surprise you're trying to avoid. In this case, I prefer not to surprise people who have come to expect that `pg' will behave identically to libpq, and who have possibly built libraries around these behaviors. It's the job of higher-level abstractions to convert the notion of a "binary string" into whatever Ruby construct corresponds to its representation by PostgreSQL.

I apologize if this makes what you're trying to do difficult. As I mentioned above, there are methods to help with escaping and unescaping bytea column values, but I'm unwilling to introduce magical conversions of any column values from a PGresult.

from ruby-pg.