Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] Extended String Types For PDO

Posted by Adam Baratz 
Adam Baratz
[PHP-DEV] [RFC] Extended String Types For PDO
February 16, 2017 05:30PM
Hi,

Based on some pain points with my team and things I've heard from others, I
created an RFC to handle "national" character sets for emulated prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

I had previously suggested this as a driver-specific change, but believe
it's worthwhile to make it generic since it affects multiple drivers:
https://externals.io/thread/400#email-12542

Please let me know what you think.

Thanks,
Adam
Adam Baratz
[PHP-DEV] Re: [RFC] Extended String Types For PDO
February 24, 2017 02:40PM
>
> Based on some pain points with my team and things I've heard from others,
> I created an RFC to handle "national" character sets for emulated prepared
> statements:
> https://wiki.php.net/rfc/extended-string-types-for-pdo
>
> I had previously suggested this as a driver-specific change, but believe
> it's worthwhile to make it generic since it affects multiple drivers:
> https://externals.io/thread/400#email-12542
>
> Please let me know what you think.
>
> Thanks,
> Adam
>
Any thoughts on this one?
Andrea Faulds
[PHP-DEV] Re: [RFC] Extended String Types For PDO
February 25, 2017 11:00PM
Hi Adam,

Adam Baratz wrote:
>>
>> Based on some pain points with my team and things I've heard from others,
>> I created an RFC to handle "national" character sets for emulated prepared
>> statements:
>> https://wiki.php.net/rfc/extended-string-types-for-pdo
>>
>> I had previously suggested this as a driver-specific change, but believe
>> it's worthwhile to make it generic since it affects multiple drivers:
>> https://externals.io/thread/400#email-12542
>>
>> Please let me know what you think.
>>
>> Thanks,
>> Adam
>>
> Any thoughts on this one?
>

It seems like a sensible proposal to me. Two points:

1. Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the
most appropriate names? For one thing, PARAM_STR_ASCII would seem to
imply such strings can only contain ASCII, but that is not the case.
Likewise, PARAM_STR_UNICODE might be understood as being required for
Unicode use, but that is also not the case. Also, both MySQL and MSSQL
refer to such strings as “national” strings, even if they are Unicode
underneath. Would it be better if the terminology we used matched these
databases', for recognisability's sake? That would also resolve
potential confusion with the constant names, they could be e.g.
PARAM_CHAR, ATTR_NATIONAL_CHAR and PARAM_NATIONAL_CHAR, or something
like that.

2. How does this interact with different character sets used for the
connection, if at all?

Thanks!

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marco Pivetta
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
February 25, 2017 11:10PM
Hi Adam

On Fri, Feb 24, 2017 at 2:28 PM, Adam Baratz <[email protected]> wrote:

> >
> > Based on some pain points with my team and things I've heard from others,
> > I created an RFC to handle "national" character sets for emulated
> prepared
> > statements:
> > https://wiki.php.net/rfc/extended-string-types-for-pdo
> >
> > I had previously suggested this as a driver-specific change, but believe
> > it's worthwhile to make it generic since it affects multiple drivers:
> > https://externals.io/thread/400#email-12542
> >
> > Please let me know what you think.
> >
> > Thanks,
> > Adam
> >
> Any thoughts on this one?
>

DBAL maintainer here: before we introduce even more complexity into the PDO
stuff (which is already a maze), could a set of test cases be written, so
that stuff that is currently impossible to do without this RFC is
clearer/demonstrated?

I'm asking because we didn't get any bug reports about extended string
types for Doctrine DBAL, and adding new types just to workaround the
limitations of the usual suspects (remember that PDO for SQLServer is
experimental, if not totally unusable) is shotgun surgery, and just more
complexity to handle.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Christopher Jones
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
February 28, 2017 05:20AM
On 26/2/17 9:07 am, Marco Pivetta wrote:

> Hi Adam
>
> On Fri, Feb 24, 2017 at 2:28 PM, Adam Baratz <[email protected]> wrote:
>
>>> Based on some pain points with my team and things I've heard from others,
>>> I created an RFC to handle "national" character sets for emulated
>> prepared
>>> statements:
>>> https://wiki.php.net/rfc/extended-string-types-for-pdo
>>>
>>> I had previously suggested this as a driver-specific change, but believe
>>> it's worthwhile to make it generic since it affects multiple drivers:
>>> https://externals.io/thread/400#email-12542
>>>
>>> Please let me know what you think.
>>>
>>> Thanks,
>>> Adam
>>>
>> Any thoughts on this one?
>>
> DBAL maintainer here: before we introduce even more complexity into the PDO
> stuff (which is already a maze), could a set of test cases be written, so
> that stuff that is currently impossible to do without this RFC is
> clearer/demonstrated?
>
> I'm asking because we didn't get any bug reports about extended string
> types for Doctrine DBAL, and adding new types just to workaround the
> limitations of the usual suspects (remember that PDO for SQLServer is
> experimental, if not totally unusable) is shotgun surgery, and just more
> complexity to handle.
>
> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
I agree the spec could definitely do with some samples and detail.

At a start, what about defining 'N-prefix' so the reader doesn't have to trawl through references?!
And clarify whether the PR is for the generic solution or the earlier problem.

More importantly, what about allowing arbitrary quote delimiters?
https://livesql.oracle.com/apex/livesql/file/content_CIREYU9EA54EOKQ7LAMZKRF6P.html

Chris

--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Adam Baratz
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
February 28, 2017 03:00PM
Merging responses here...

Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the most
> appropriate names?


Good point. Maybe instead:

- PDO::PARAM_STR_NATL
- PDO::ATTR_NATL_STRINGS
- PDO::PARAM_STR_CHAR

How does this interact with different character sets used for the
> connection, if at all?


I don't think that should matter. This is strictly a hint for the quote
functions to put an "N" at the beginning of their output.

DBAL maintainer here: before we introduce even more complexity into the PDO
> stuff (which is already a maze), could a set of test cases be written, so
> that stuff that is currently impossible to do without this RFC is
> clearer/demonstrated?
>

The other RFC I mentioned included a similar solution to this problem. The
PR I put together for that should make this clear enough:
https://github.com/php/php-src/pull/2168


> I'm asking because we didn't get any bug reports about extended string
> types for Doctrine DBAL, and adding new types just to workaround the
> limitations of the usual suspects is shotgun surgery, and just more
> complexity to handle.
>

I think of them more like flags, like PDO::PARAM_INPUT_OUTPUT, than
standalone types. Since you apply with a bitwise-OR, the addition would be
minimally invasive. And you wouldn't have to rewrite code if you switch
drivers. The flags would simply be ignored.

(remember that PDO for SQLServer is experimental, if not totally unusable)
>

I'm mainly interested in pdo_dblib, which is an officially maintained
extension (I'm the maintainer). I assume you're referring to pdo_sqlsrv?

More importantly, what about allowing arbitrary quote delimiters?

https://livesql.oracle.com/apex/livesql/file/content_CIREYU9
> EA54EOKQ7LAMZKRF6P.html


This functionality seems orthogonal to what I'm describing. It would be
more appropriate to implement this as a driver-specific attribute for
pdo_oci. But since that driver doesn't support emulated prepares, I'm not
sure how much value it would have.

Thanks,
Adam
Christopher Jones
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 01, 2017 02:10AM
On 1/3/17 12:58 am, Adam Baratz wrote:
> Merging responses here...
>
> Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the most appropriate names?
>
>
> Good point. Maybe instead:
>
> * PDO::PARAM_STR_NATL
> * PDO::ATTR_NATL_STRINGS
> * PDO::PARAM_STR_CHAR
>
> How does this interact with different character sets used for the connection, if at all?
>
>
> I don't think that should matter. This is strictly a hint for the quote functions to put an "N" at the beginning of their output.
>
> DBAL maintainer here: before we introduce even more complexity into the PDO stuff (which is already a maze), could a set of test cases be
> written, so that stuff that is currently impossible to do without this RFC is clearer/demonstrated?
>
>
> The other RFC I mentioned included a similar solution to this problem. The PR I put together for that should make this clear enough:
> https://github.com/php/php-src/pull/2168 https://github.com/php/php-src/pull/2168
>
> I'm asking because we didn't get any bug reports about extended string types for Doctrine DBAL, and adding new types just to workaround the
> limitations of the usual suspects is shotgun surgery, and just more complexity to handle.
>
>
> I think of them more like flags, like PDO::PARAM_INPUT_OUTPUT, than standalone types. Since you apply with a bitwise-OR, the addition would be
> minimally invasive. And you wouldn't have to rewrite code if you switch drivers. The flags would simply be ignored.
>
> (remember that PDO for SQLServer is experimental, if not totally unusable)
>
>
> I'm mainly interested in pdo_dblib, which is an officially maintained extension (I'm the maintainer). I assume you're referring to pdo_sqlsrv?
>
> More importantly, what about allowing arbitrary quote delimiters?
>
> https://livesql.oracle.com/apex/livesql/file/content_CIREYU9EA54EOKQ7LAMZKRF6P.html
> https://livesql.oracle.com/apex/livesql/file/content_CIREYU9EA54EOKQ7LAMZKRF6P.html
>
>
> This functionality seems orthogonal to what I'm describing. It would be more appropriate to implement this as a driver-specific attribute for
> pdo_oci. But since that driver doesn't support emulated prepares, I'm not sure how much value it would have.

Isn't the same quoting functionality available via the quote() method? That's what the PR's tests use.

I don't think it's orthogonal. There are various ways to quote strings and a generic PDO solution should be flexible enough to handle all drivers.

Chris
>
> Thanks,
> Adam

--
http://twitter.com/ghrd
Adam Baratz
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 01, 2017 09:10PM
>
> Isn't the same quoting functionality available via the quote() method?
> That's what the PR's tests use.
>

> I don't think it's orthogonal. There are various ways to quote strings
> and a generic PDO solution should be flexible enough to handle all drivers.
>

Yes, they fit into the same general topic of string quoting, but I'd assign
different levels of importance to national charset literals and alternate
delimiters. Not being able to quote national charset literals means you
can't produce correctly formed queries with two drivers. My understanding
of alternate delimiters is that they make it easier to hand-writing
queries. The quote function may not generate the most human-readable
queries for some input, but the queries will be valid.

There are a couple other complexities for alternate delimiters. Not all
databases allow them and the options vary for each. For example,
PostgreSQL's only alternative is dollar-quoting[1]. If you think it's
important to handle this functionality, I think a separate RFC would be
more appropriate. My guess is instance/statement attributes would be the
better mechanism to control delimiters and you might want them to be
driver-specific.

Thanks,
Adam

---
[1]
https://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING
Adam Baratz
[PHP-DEV] Re: [RFC] Extended String Types For PDO
March 03, 2017 04:50PM
>
> Based on some pain points with my team and things I've heard from others,
> I created an RFC to handle "national" character sets for emulated prepared
> statements:
> https://wiki.php.net/rfc/extended-string-types-for-pdo
>

Thanks all for the feedback so far. I updated the RFC based on what I
heard. Hopefully it clarifies some of the ambiguities mentioned and the
motivation for making this change. It's ultimately about helping PDO
articulate part of the SQL spec.

Let me know if you have any new questions/concerns.

Adam
Andrea Faulds
[PHP-DEV] Re: [RFC] Extended String Types For PDO
March 03, 2017 05:00PM
Hi,

Adam Baratz wrote:
>>
>> Based on some pain points with my team and things I've heard from others,
>> I created an RFC to handle "national" character sets for emulated prepared
>> statements:
>> https://wiki.php.net/rfc/extended-string-types-for-pdo
>>
>
> Thanks all for the feedback so far. I updated the RFC based on what I
> heard. Hopefully it clarifies some of the ambiguities mentioned and the
> motivation for making this change. It's ultimately about helping PDO
> articulate part of the SQL spec.

The updated RFC is a lot clearer, thanks!



--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marco Pivetta
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 06, 2017 08:50AM
Reading some random documents online (bear with me, doing it from the
phone), this seems to be irrelevant for MySQL, and an edge case dealing
with MSSQL. Is there a runnable functional test case demonstrating the
practical issue behind this addition?

Asking because of the same reasons I posted above.

On 3 Mar 2017 4:47 p.m., "Adam Baratz" <[email protected]> wrote:

> >
> > Based on some pain points with my team and things I've heard from others,
> > I created an RFC to handle "national" character sets for emulated
> prepared
> > statements:
> > https://wiki.php.net/rfc/extended-string-types-for-pdo
> >
>
> Thanks all for the feedback so far. I updated the RFC based on what I
> heard. Hopefully it clarifies some of the ambiguities mentioned and the
> motivation for making this change. It's ultimately about helping PDO
> articulate part of the SQL spec.
>
> Let me know if you have any new questions/concerns.
>
> Adam
>
Adam Baratz
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 06, 2017 04:40PM
>
> Reading some random documents online (bear with me, doing it from the
> phone), this seems to be irrelevant for MySQL, and an edge case dealing
> with MSSQL. Is there a runnable functional test case demonstrating the
> practical issue behind this addition?
>

I wouldn't characterize this as edge case for MSSQL. Implicit casts have
very real costs:
https://www.sqlskills.com/blogs/jonathan/implicit-conversions-that-cause-index-scans/

Part of my day job is supporting hundreds of engineers who use PHP to query
MSSQL. Our DBAs are very adamant about making sure we quote strings
correctly. We have a hackish solution for this. Since other pdo_dblib users
have asked for a solution, I wanted to work out a non-hackish solution that
could make it into master. Since these column types are part of SQL-92 and
the issue could also affect pdo_mysql, I wanted to make it a generic
solution.

I'm admittedly less familiar with MySQL than MSSQL, but this blog post has
some examples of implicit casts affecting performance:
http://code.openark.org/blog/mysql/beware-of-implicit-casting

Could you share more details around why you think this change is
irrelevant/unimportant? Or let me know how I should document things better
in the RFC?

Thanks,
Adam
Matteo Beccati
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 09, 2017 11:10AM
Hi Adam,

On 03/03/2017 16:47, Adam Baratz wrote:
>>
>> Based on some pain points with my team and things I've heard from others,
>> I created an RFC to handle "national" character sets for emulated prepared
>> statements:
>> https://wiki.php.net/rfc/extended-string-types-for-pdo
>>
>
> Thanks all for the feedback so far. I updated the RFC based on what I
> heard. Hopefully it clarifies some of the ambiguities mentioned and the
> motivation for making this change. It's ultimately about helping PDO
> articulate part of the SQL spec.
>
> Let me know if you have any new questions/concerns.

I'm sorry for being late to the party. I too have some doubts, but
having clarified the fact that national character types are a SQL-92
standard clears some of them.

However, I see no reference about the expected input/output encoding
(Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
match the internal encoding of the driver (e.g. UTF-16?)? What happens
if I try to quote a latin1 string?


Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marco Pivetta
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 09, 2017 03:10PM
On Thu, Mar 9, 2017 at 5:03 AM, Matteo Beccati <[email protected]> wrote:

> Hi Adam,
>
> On 03/03/2017 16:47, Adam Baratz wrote:
> >>
> >> Based on some pain points with my team and things I've heard from
> others,
> >> I created an RFC to handle "national" character sets for emulated
> prepared
> >> statements:
> >> https://wiki.php.net/rfc/extended-string-types-for-pdo
> >>
> >
> > Thanks all for the feedback so far. I updated the RFC based on what I
> > heard. Hopefully it clarifies some of the ambiguities mentioned and the
> > motivation for making this change. It's ultimately about helping PDO
> > articulate part of the SQL spec.
> >
> > Let me know if you have any new questions/concerns.
>
> I'm sorry for being late to the party. I too have some doubts, but
> having clarified the fact that national character types are a SQL-92
> standard clears some of them.
>
> However, I see no reference about the expected input/output encoding
> (Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
> match the internal encoding of the driver (e.g. UTF-16?)? What happens
> if I try to quote a latin1 string?
>

Since I am still skeptical about this, I asked around and told people to
bind parameters with unicode strings and poke me back: works correctly.
So what is this addition doing exactly? Shouldn't this be treated as an SQL
Server *BUG* instead? Why push it on the toolchain?

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Adam Baratz
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 09, 2017 05:10PM
>
> However, I see no reference about the expected input/output encoding
> (Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
> match the internal encoding of the driver (e.g. UTF-16?)? What happens
> if I try to quote a latin1 string?


I think this is mostly covered by my BC note: "These constants wouldn't
affect anything related to the character set used for connections." My only
intentions with my proposed change is to let people prepend an "N" to some
quoted values. The pdo_mysql and pdo_dblib quote functions are otherwise
ignorant of encoding. It's all bytes to them. There are different hooks to
set the encoding for a connection. I'm not aware of issues with either
extension dealing with multibyte characters in output.

If that doesn't make sense, pass on a code snippet and I can think through
how it would work.

Since I am still skeptical about this, I asked around and told people to
> bind parameters with unicode strings and poke me back: works correctly.
> So what is this addition doing exactly? Shouldn't this be treated as an
> SQL Server *BUG* instead? Why push it on the toolchain?
>

It is true that you get the correct result right now. But this happens
because the DB will automatically cast values that are quoted incorrectly.
This addition would ensures that quoted values don't have an implicit cast
applied, which makes queries more expensive. I can put the links I shared
earlier into the RFC for easier reference.

Thanks,
Adam
Marco Pivetta
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 10, 2017 07:30AM
Hey Adam,

On Thu, Mar 9, 2017 at 11:07 AM, Adam Baratz <[email protected]> wrote:

> However, I see no reference about the expected input/output encoding
>> (Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
>> match the internal encoding of the driver (e.g. UTF-16?)? What happens
>> if I try to quote a latin1 string?
>
>
> I think this is mostly covered by my BC note: "These constants wouldn't
> affect anything related to the character set used for connections." My only
> intentions with my proposed change is to let people prepend an "N" to some
> quoted values. The pdo_mysql and pdo_dblib quote functions are otherwise
> ignorant of encoding. It's all bytes to them. There are different hooks to
> set the encoding for a connection. I'm not aware of issues with either
> extension dealing with multibyte characters in output.
>
> If that doesn't make sense, pass on a code snippet and I can think through
> how it would work.
>
> Since I am still skeptical about this, I asked around and told people to
>> bind parameters with unicode strings and poke me back: works correctly.
>> So what is this addition doing exactly? Shouldn't this be treated as an
>> SQL Server *BUG* instead? Why push it on the toolchain?
>>
>
> It is true that you get the correct result right now. But this happens
> because the DB will automatically cast values that are quoted incorrectly.
> This addition would ensures that quoted values don't have an implicit cast
> applied, which makes queries more expensive. I can put the links I shared
> earlier into the RFC for easier reference.
>
> Thanks,
> Adam
>

I've read the links, hence my skepticism and me labeling this as "yet
another way that SQL Server decides to make things harder and buggy". It is
a bug in SQL Server, unless I'm missing the reason for this to exist (or
maybe there was such a reason in 1991).

As for BC compliance, this will still break code, as current overrides to
prepared statements (in DBAL, specifically) directly compare the parameter
type to a constant (no bitmask comparison).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Adam Baratz
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 10, 2017 05:00PM
>
> I've read the links, hence my skepticism and me labeling this as "yet
> another way that SQL Server decides to make things harder and buggy". It is
> a bug in SQL Server, unless I'm missing the reason for this to exist (or
> maybe there was such a reason in 1991).
>

One of the links is MySQL specific. Apart from that, it's not accurate to
characterize this as a bug with MSSQL. They used part of the SQL spec in an
intended way. Yes, it's a little more cumbersome than having a single
string type, but it doesn't help PDO users to wish other designs onto DBs.

As for BC compliance, this will still break code, as current overrides to
> prepared statements (in DBAL, specifically) directly compare the parameter
> type to a constant (no bitmask comparison).
>

I meant that this change won't break existing code. But yes, others may
need to modify their code to be compatible with this new feature. Within
pdo, a bitmask is applied -- see uses of the PDO_PARAM_TYPE macro. It's
probably worth replicating that in DBAL.

Thanks,
Adam
Matteo Beccati
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 10, 2017 05:50PM
On 10/03/2017 16:53, Adam Baratz wrote:
> I meant that this change won't break existing code. But yes, others may
> need to modify their code to be compatible with this new feature. Within
> pdo, a bitmask is applied -- see uses of the PDO_PARAM_TYPE macro. It's
> probably worth replicating that in DBAL.

I'm sorry, I think it's too disruptive both for userland and drivers
developers. For very little gain, if I may.


Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Adam Baratz
[PHP-DEV] Re: [RFC] Extended String Types For PDO
March 17, 2017 03:00PM
>
> Based on some pain points with my team and things I've heard from others,
> I created an RFC to handle "national" character sets for emulated prepared
> statements:
> https://wiki.php.net/rfc/extended-string-types-for-pdo
>

The vote closed and this RFC was accepted. Thanks all for your feedback and
votes.

Adam
Marco Pivetta
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 18, 2017 12:40PM
Wait, when was the vote opened? I didn't receive any notification of that
(and therefore didn't vote yet), and we were still telling you in this
thread that there are fundamental conceptual issues with the backing
reasoning.

On 17 Mar 2017 2:54 p.m., "Adam Baratz" <[email protected]> wrote:

> >
> > Based on some pain points with my team and things I've heard from others,
> > I created an RFC to handle "national" character sets for emulated
> prepared
> > statements:
> > https://wiki.php.net/rfc/extended-string-types-for-pdo
> >
>
> The vote closed and this RFC was accepted. Thanks all for your feedback and
> votes.
>
> Adam
>
Christoph M. Becker
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 18, 2017 02:50PM
On 18.03.2017 at 12:29, Marco Pivetta wrote:

> Wait, when was the vote opened? I didn't receive any notification of that
> (and therefore didn't vote yet), and we were still telling you in this
> thread that there are fundamental conceptual issues with the backing
> reasoning.

Adam announced the vote on March, 8th, see
http://news.php.net/php.internals/98447. The voting result was 8:1,
by the way.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Adam Baratz
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 19, 2017 03:30AM
>
> > Wait, when was the vote opened? I didn't receive any notification of that
> > (and therefore didn't vote yet), and we were still telling you in this
> > thread that there are fundamental conceptual issues with the backing
> > reasoning.
>
> Adam announced the vote on March, 8th, see
> http://news.php.net/php.internals/98447. The voting result was 8:1,
> by the way.
>

Sorry that you felt discussion was cut short. I tried to document the need
for this change as clearly as I could. It felt like we were going in
circles on this point, that you were going to vote against the RFC no
matter what. Let me know if I misunderstood something. This probably won't
be the last PDO-related RFC I write. I want to be an effective collaborator
with you and the rest of the community.

It should be possible to update DBAL so it will be unaffected by this
change. If you're still concerned about that, I'd be happy to discuss
off-list.

Thanks,
Adam
Rowan Collins
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 19, 2017 03:00PM
On 18/03/2017 13:38, Christoph M. Becker wrote:
> On 18.03.2017 at 12:29, Marco Pivetta wrote:
>
>> Wait, when was the vote opened? I didn't receive any notification of that
>> (and therefore didn't vote yet), and we were still telling you in this
>> thread that there are fundamental conceptual issues with the backing
>> reasoning.
> Adam announced the vote on March, 8th, see
> http://news.php.net/php.internals/98447. The voting result was 8:1,
> by the way.
>

I did think it was surprising that this RFC only had 9 votes registered,
when the one I opened around the same time currently has 29, so I wonder
if Marco wasn't the only one who overlooked it?

However, I received the notification fine, and it was picked up by the
SO chat bot, https://php-rfc-watch.beberlei.de/, etc, so it may just be
that a lot of people were aware but decided to abstain.

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Levi Morrison
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 19, 2017 08:10PM
On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins <[email protected]> wrote:
> On 18/03/2017 13:38, Christoph M. Becker wrote:
>>
>> On 18.03.2017 at 12:29, Marco Pivetta wrote:
>>
>>> Wait, when was the vote opened? I didn't receive any notification of that
>>> (and therefore didn't vote yet), and we were still telling you in this
>>> thread that there are fundamental conceptual issues with the backing
>>> reasoning.
>>
>> Adam announced the vote on March, 8th, see
>> http://news.php.net/php.internals/98447. The voting result was 8:1,
>> by the way.
>>
>
> I did think it was surprising that this RFC only had 9 votes registered,
> when the one I opened around the same time currently has 29, so I wonder if
> Marco wasn't the only one who overlooked it?
>
> However, I received the notification fine, and it was picked up by the SO
> chat bot, https://php-rfc-watch.beberlei.de/, etc, so it may just be that a
> lot of people were aware but decided to abstain.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

We currently do not have any provision for requiring at least a
certain amount of votes, but in my opinion it would be prudent to do
so for cases like this. With only *nine* contributors voting and it
not even being unanimous I feel like it shouldn't pass. Anyone who is
gathering notes for a voting rework proposal should take note.

And of course RFCs should only be held to the agreed rules of the
time, so I'm not saying we should reject this RFC.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jakub Zelenka
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 19, 2017 08:40PM
On 19 Mar 2017 19:01, "Levi Morrison" <[email protected]> wrote:

On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins <[email protected]>
wrote:
> On 18/03/2017 13:38, Christoph M. Becker wrote:
>>
>> On 18.03.2017 at 12:29, Marco Pivetta wrote:
>>
>>> Wait, when was the vote opened? I didn't receive any notification of
that
>>> (and therefore didn't vote yet), and we were still telling you in this
>>> thread that there are fundamental conceptual issues with the backing
>>> reasoning.
>>
>> Adam announced the vote on March, 8th, see
>> http://news.php.net/php.internals/98447. The voting result was 8:1,
>> by the way.
>>
>
> I did think it was surprising that this RFC only had 9 votes registered,
> when the one I opened around the same time currently has 29, so I wonder
if
> Marco wasn't the only one who overlooked it?
>
> However, I received the notification fine, and it was picked up by the SO
> chat bot, https://php-rfc-watch.beberlei.de/, etc, so it may just be that
a
> lot of people were aware but decided to abstain.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

We currently do not have any provision for requiring at least a
certain amount of votes, but in my opinion it would be prudent to do
so for cases like this. With only *nine* contributors voting and it
not even being unanimous I feel like it shouldn't pass. Anyone who is
gathering notes for a voting rework proposal should take note.


I completely disagree with this. If there is not enough votes, it means
that poeple either don't care (possibly don't have time or don't read
properly mailing list) or don't understand the proposed thing. I think it
shousld up to the maintainer to decide in such case and not to block a
feature because not enaugh people is interested in it. But even if we leave
it as it is (accept it with only few votes) it is still much better than
block it if there is no interest.
Levi Morrison
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 19, 2017 09:00PM
In

On Sun, Mar 19, 2017 at 1:32 PM, Jakub Zelenka <[email protected]> wrote:
>
>
> On 19 Mar 2017 19:01, "Levi Morrison" <le[email protected]> wrote:
>
> On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins <[email protected]>
> wrote:
>> On 18/03/2017 13:38, Christoph M. Becker wrote:
>>>
>>> On 18.03.2017 at 12:29, Marco Pivetta wrote:
>>>
>>>> Wait, when was the vote opened? I didn't receive any notification of
>>>> that
>>>> (and therefore didn't vote yet), and we were still telling you in this
>>>> thread that there are fundamental conceptual issues with the backing
>>>> reasoning.
>>>
>>> Adam announced the vote on March, 8th, see
>>> http://news.php.net/php.internals/98447. The voting result was 8:1,
>>> by the way.
>>>
>>
>> I did think it was surprising that this RFC only had 9 votes registered,
>> when the one I opened around the same time currently has 29, so I wonder
>> if
>> Marco wasn't the only one who overlooked it?
>>
>> However, I received the notification fine, and it was picked up by the SO
>> chat bot, https://php-rfc-watch.beberlei.de/, etc, so it may just be that
>> a
>> lot of people were aware but decided to abstain.
>>
>> Regards,
>>
>> --
>> Rowan Collins
>> [IMSoP]
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
> We currently do not have any provision for requiring at least a
> certain amount of votes, but in my opinion it would be prudent to do
> so for cases like this. With only *nine* contributors voting and it
> not even being unanimous I feel like it shouldn't pass. Anyone who is
> gathering notes for a voting rework proposal should take note.
>
>
> I completely disagree with this. If there is not enough votes, it means that
> poeple either don't care (possibly don't have time or don't read properly
> mailing list) or don't understand the proposed thing.

If this is the case then why on earth should it be in core?

> I think it should up
> to the maintainer to decide in such case and not to block a feature because
> not enaugh people is interested in it.

If it's up to the maintainer then it didn't need an RFC anyway.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jakub Zelenka
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 19, 2017 10:20PM
On 19 Mar 2017 19:51, "Levi Morrison" <[email protected]> wrote:

In

On Sun, Mar 19, 2017 at 1:32 PM, Jakub Zelenka <[email protected]> wrote:
>
>
> On 19 Mar 2017 19:01, "Levi Morrison" <[email protected]> wrote:
>
> On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins <[email protected]>
> wrote:
>> On 18/03/2017 13:38, Christoph M. Becker wrote:
>>>
>>> On 18.03.2017 at 12:29, Marco Pivetta wrote:
>>>
>>>> Wait, when was the vote opened? I didn't receive any notification of
>>>> that
>>>> (and therefore didn't vote yet), and we were still telling you in this
>>>> thread that there are fundamental conceptual issues with the backing
>>>> reasoning.
>>>
>>> Adam announced the vote on March, 8th, see
>>> http://news.php.net/php.internals/98447. The voting result was 8:1,
>>> by the way.
>>>
>>
>> I did think it was surprising that this RFC only had 9 votes registered,
>> when the one I opened around the same time currently has 29, so I wonder
>> if
>> Marco wasn't the only one who overlooked it?
>>
>> However, I received the notification fine, and it was picked up by the SO
>> chat bot, https://php-rfc-watch.beberlei.de/, etc, so it may just be that
>> a
>> lot of people were aware but decided to abstain.
>>
>> Regards,
>>
>> --
>> Rowan Collins
>> [IMSoP]
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
> We currently do not have any provision for requiring at least a
> certain amount of votes, but in my opinion it would be prudent to do
> so for cases like this. With only *nine* contributors voting and it
> not even being unanimous I feel like it shouldn't pass. Anyone who is
> gathering notes for a voting rework proposal should take note.
>
>
> I completely disagree with this. If there is not enough votes, it means
that
> poeple either don't care (possibly don't have time or don't read
properly
> mailing list) or don't understand the proposed thing.

If this is the case then why on earth should it be in core?

I actually mean voters when I say people in this case. Just the fact that
voters don't care about this feature doesn't mean that it's not useful.
What I want to say is that not enaough interest from voters or even
contributors shouldn't block the proposed feature.

> I think it should up
> to the maintainer to decide in such case and not to block a feature
because
> not enaugh people is interested in it.

If it's up to the maintainer then it didn't need an RFC anyway.


Well I'm not saying it's up to the maintainers. I just think it should up
to the maintainers to decide such things. Anyway it's already the case that
there isn't any reason for having a vote if there are no objections.
However there were some objections in this case. So I understand why there
was a vote. Just the fact there wasn't enough people voting against it
says to me that the objections are not really relevant and the feature
should be accepted. Especially if it's proposed one of the PDO related core
extension mantainer. It means that having some required limit on number of
voters to accept RFC seems like a really bad idea to me.

Cheers

Jakub
Rowan Collins
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 19, 2017 10:20PM
On 19/03/2017 19:32, Jakub Zelenka wrote:
> I completely disagree with this. If there is not enough votes, it
> means that poeple either don't care (possibly don't have time or
> don't read properly mailing list) or don't understand the proposed thing.

Yes, those are the most likely reasons. There is also the possibility
that for some technical or timing reason people missed the announcement.


> I think it shousld up to the maintainer to decide in such case and not
> to block a feature because not enaugh people is interested in it.

There is currently nobody authorised to make that decision, and granting
it to extension maintainers feels like a significant change to that
role. As I understand it, one of the big differences between a PECL
extension and a bundled one is that once in core, it's subject to
decision-making by the whole project, not the authors of the code.


> But even if we leave it as it is (accept it with only few votes) it is
> still much better than block it if there is no interest.

The entire RFC and voting process assumes that "no change" is the
default option - a language change requires two-thirds to make the
change, not two-thirds to reject it. If there were a "quorum" rule, it
would be entirely consistent for not enough votes to have the same
effect as an insufficiently large majority, and reject the change.

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jakub Zelenka
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 19, 2017 11:00PM
On 19 Mar 2017 21:19, "Rowan Collins" <[email protected]> wrote:

On 19/03/2017 19:32, Jakub Zelenka wrote:

> I completely disagree with this. If there is not enough votes, it means
> that poeple either don't care (possibly don't have time or don't read
> properly mailing list) or don't understand the proposed thing.
>

Yes, those are the most likely reasons. There is also the possibility that
for some technical or timing reason people missed the announcement.



I think it shousld up to the maintainer to decide in such case and not to
> block a feature because not enaugh people is interested in it.
>

There is currently nobody authorised to make that decision, and granting it
to extension maintainers feels like a significant change to that role. As I
understand it, one of the big differences between a PECL extension and a
bundled one is that once in core, it's subject to decision-making by the
whole project, not the authors of the code.


I don't really think that we any definition for mantainer role. Currently
it varies depending on the extension. For example you won't see many RFC's
in date ext which is very well maintained by Derick and most of the changes
are decided by him which I think is a very good thing and works very well.




But even if we leave it as it is (accept it with only few votes) it is
> still much better than block it if there is no interest.
>

The entire RFC and voting process assumes that "no change" is the default
option - a language change requires two-thirds to make the change, not
two-thirds to reject it. If there were a "quorum" rule, it would be
entirely consistent for not enough votes to have the same effect as an
insufficiently large majority, and reject the change.


Sorry but I just don't agree with that. We are talking about a feature for
PDO that not many voters is interested in. That's completely different than
a language change. The interest in other core extensions is often the same.
If we had such rule on the minimal number of votes, one person could easily
block any progress on the any extension. It would not only slow down the
development but also annoy maintainers and people working on extension.
That's just a very bad idea IMHO.

Cheers

Jakub
Rowan Collins
Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
March 20, 2017 12:20AM
On 19/03/2017 21:54, Jakub Zelenka wrote:
> I don't really think that we any definition for mantainer role.
> Currently it varies depending on the extension. For example you won't
> see many RFC's in date ext which is very well maintained by Derick and
> most of the changes are decided by him which I think is a very good
> thing and works very well.

[...]

> Sorry but I just don't agree with that. We are talking about a feature
> for PDO that not many voters is interested in. That's completely
> different than a language change. The interest in other core
> extensions is often the same.

Fair points. I'm not sure the RFC process as a whole works well for
specialist decisions - the same has come up with very technical Engine
changes.

I think this kind of breaks down into two questions:

- Which changes need an RFC?
- If a change does need an RFC, what level of support does it need?

I don't have particularly good answers, but "this change shouldn't have
needed an RFC in the first place" is a very different direction from
"after the RFC has been debated, this person should have a veto /
casting vote". I realise that's not what you were suggesting, though,
and I'm happy to go with "the current system is not really a problem".


> If we had such rule on the minimal number of votes, one person could
> easily block any progress on the any extension.

I am a little curious what you meant by this, though; I can't see how it
follows at all.

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login