Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Extended String Types For PDO »

[RFC] Extended String Types For PDO

php.internals

Adam Baratz

9 years ago
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

9 years ago
> > 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?

Andrew Faulds

9 years ago
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/

Marco Pivetta

9 years ago
Hi Adam On Fri, Feb 24, 2017 at 2:28 PM, Adam Baratz <adam.baratz@gmail.com> 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

9 years ago
On 26/2/17 9:07 am, Marco Pivetta wrote:
> Hi Adam > > On Fri, Feb 24, 2017 at 2:28 PM, Adam Baratz <adam.baratz@gmail.com> 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

Adam Baratz

9 years ago
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

9 years ago
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

9 years ago
> > 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

9 years ago
> > 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

Andrew Faulds

9 years ago
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/

Marco Pivetta

9 years ago
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" <adam.baratz@gmail.com> wrote:

Adam Baratz

9 years ago
> > 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

9 years ago
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/

Marco Pivetta

9 years ago
On Thu, Mar 9, 2017 at 5:03 AM, Matteo Beccati <php@beccati.com> 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

9 years ago
> > 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

9 years ago
Hey Adam, On Thu, Mar 9, 2017 at 11:07 AM, Adam Baratz <adam.baratz@gmail.com> 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

9 years ago
> > 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

9 years ago
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/

Adam Baratz

9 years ago
> > 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

9 years ago
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" <adam.baratz@gmail.com> wrote:

Christoph Becker

9 years ago
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

Adam Baratz

9 years ago
> > > 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

9 years ago
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]

Levi Morrison

9 years ago
On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins <rowan.collins@gmail.com> 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.

Jakub Zelenka

9 years ago
On 19 Mar 2017 19:01, "Levi Morrison" <levim@php.net> wrote: On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins <rowan.collins@gmail.com> 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

9 years ago
In On Sun, Mar 19, 2017 at 1:32 PM, Jakub Zelenka <bukka@php.net> wrote:
> > > On 19 Mar 2017 19:01, "Levi Morrison" <levim@php.net> wrote: > > On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins <rowan.collins@gmail.com> > 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.

Rowan Collins

9 years ago
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]

Jakub Zelenka

9 years ago
On 19 Mar 2017 21:19, "Rowan Collins" <rowan.collins@gmail.com> 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

9 years ago
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]

Matteo Beccati

9 years ago
On 18/03/2017 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.
Ha! I was wondering why you didn't vote just yet and here's the answer. Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/