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
On 20/03/17 00:25, Marco Pivetta wrote:
> Given that most installs of Doctrine DBAL (80%+) rely on PDO MySQL, that's
> quite a lot of users: https://packagist.org/packages/doctrine/dbal/stats
>
> PDO is currently the leading DB abstraction in PHP projects, regardless of
> how horrible its API is.
On Mon, Mar 20, 2017 at 12:57 AM, Lester Caine wrote:
> On 19/03/17 23:11, Rowan Collins wrote:
> >> 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
On 19/03/17 23:11, Rowan Collins wrote:
>> 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.
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
On 19 Mar 2017 21:19, "Rowan Collins" 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
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.
On 19 Mar 2017 19:51, "Levi Morrison" wrote:
In
On Sun, Mar 19, 2017 at 1:32 PM, Jakub Zelenka wrote:
>
>
> On 19 Mar 2017 19:01, "Levi Morrison" wrote:
>
> On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins
> wrote:
>> On
In
On Sun, Mar 19, 2017 at 1:32 PM, Jakub Zelenka wrote:
>
>
> On 19 Mar 2017 19:01, "Levi Morrison" wrote:
>
> On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins
> wrote:
>> On 18/03/2017 13:38, Christoph M. Becker wrote:
>>>
>>> On
On 19 Mar 2017 19:01, "Levi Morrison" wrote:
On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins
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
On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins 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),
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
>
> > 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
>
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
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" 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
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
>
> 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
Hey Adam,
On Thu, Mar 9, 2017 at 11:07 AM, Adam Baratz 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
>
> 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
On Thu, Mar 9, 2017 at 5:03 AM, Matteo Beccati 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
>
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
>
> 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
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
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
>
> 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
>
> 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
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
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
>
On 26/2/17 9:07 am, Marco Pivetta wrote:
Hi Adam
On Fri, Feb 24, 2017 at 2:28 PM, 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:
Hi Adam
On Fri, Feb 24, 2017 at 2:28 PM, 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:
> >
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
>
> 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
33 matches
Mail list logo