New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API issue: Connection#$encoding #20
Comments
Implementing this as property was probably a bad idea, so, should we add a method and deprecate the public property? |
The ideal solution to implement lazy async connection :) $db = new Connection($dsn); // new instance, not real connection to server
$db->encoding = 'UTF-8'; // if not or bad connect - save value, for deferred execute
yield from $db->exec($sql); // if not or bad connect - async connect and execute deferred query I understand that it is very difficult, but it will be very convenient to use in userland. |
If the main concern is setting the encoding for an async connection, it's probably best to use the client_encoding connection string parameter: http://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-CONNECT-CLIENT-ENCODING |
So I personally don't have any issues with a property assignment throwing. It's something other OO languages do all the time. However, I will concede that it's not "the PHP way" and it would also be more of a BC issue than deprecating the property and replacing it with a pair of methods, so I'm happy to go with that. I'll check over the rest of the API for anything else that might present a similar problem. |
|
Assigning this can fail. At the moment this can't be easily detected without installing global error handlers (it currently emits an
E_NOTICE
ext-pq/src/php_pqconn.c
Line 199 in 75f3b1b
As this is something that could contribute to a security issue if it fails, can we throw an exception instead? A failure to set an encoding anywhere should always be handled - or at least handle-able - IMHO.
The text was updated successfully, but these errors were encountered: