Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

> > It's possible that daverandom was several hours west of Greenwich at the > time (e.g. in North America), where it was still late on October 27th. So > taking the latest of the three published closing dates, and applying the > most generous time zone, it's possible that all the votes were valid.

Re: [PHP-DEV] Re: [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

> > PDO already has support for large objects (LOBs)[1]. I don't know if >>> and how these are supported by the pdo_sqlite driver, but wouldn't it >>> make sense to use the existing API instead of introducing a new >>> method? >>> >>> [1] >>> >>> >> Very

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

> > following my patch and discussions on this list, here is the RFC requested > by some people here to implement "openBlob" in the pdo_sqlite driver, to > match the "openBlob" method from the SQLite3 extension. Thanks for taking the time to do the writeup. No objections from me. Adam

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

> > That change was implemented in the SQLite3 extension without a RFC, so I'm > quite confused here. > My literal reading of the contribution guide[1] is that new features should be preceded by an RFC, though there are certainly cases where this doesn't happen. I don't have a clear enough underst

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

On Mon, Aug 21, 2017 at 5:54 PM, BohwaZ/PHP wrote: > Le 22/08/2017 07:55, Adam Baratz a écrit : > >> A new method is an API change to me, so an RFC would be warranted. I'm >> reluctant to add driver-specific methods, since that seems opposed to >> PDO's >>

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

> > I just have proposed a patch to have SQLite3 open_blob feature implemented > in PDO_SQLite: https://github.com/php/php-src/pull/2698 [cross-posted from GitHub] A new method is an API change to me, so an RFC would be warranted. I'm reluctant to add driver-specific methods, since that seems op

Re: [PHP-DEV] PDO ODBC #42765 uninitialized length bug patch

On Wed, Jun 21, 2017 at 11:32 AM Christoph M. Becker wrote: > On 21.06.2017 at 05:33, Anish Mistry wrote: > > > PDO ODBC #42765 uninitialized length bug patch > > https://bugs.php.net/bug.php?id=42765 > > > > Any takers? Would we be able to get this patch committed? It's a > > pretty straight f

[PHP-DEV] Re: PDO Parameter types // PDO::PARAM_AUTO

> > > The risk with this is queries could lose portability between drivers. > There are differences in the level of information each one can get from the > DB server, and different costs associated with asking. > > I think the right model is to have PDO types map directly to SQL types. > That said,

Re: [PHP-DEV] Re: [VOTE] PDO Float Type

> > If you search the archives, you might find that I wasn't happy to have > PARAM_FLOAT without some kind of PARAM_NUMERIC. You're basically saying > that my point was irrelevant and out of scope. Aww, thanks ;) > I'm sorry my update sounded like I was ignoring your feedback. Another change was m

[PHP-DEV] Re: PDO Parameter types // PDO::PARAM_AUTO

> > Who is the architector/staff board of PDO? PDO is maintained with the rest of PHP core, so it follows the same process outlined in CONTRIBUTING.md. That is to say, there's no central governance. Some people, as listed in EXTENSIONS, have appropriate karma and handle maintenance that falls out

Re: [PHP-DEV] [RFC] deprecate PDO::PARAM_NULL

> > "A handful of people on the internals mail list have asked for it to be > removed" - where and when? > I didn't mean this as a justification or as any kind of vote, just as a prompt for a formal discussion. "Supporting it adds some weight to PDO" what kind of weight? How many > lines / micros

Re: [PHP-DEV] messages not delivering?

> > I'm think this problem might've cropped up again. I didn't receive this > > message: > > http://news.php.net/php.internals/99052 > > > > I only heard about it because it was mentioned in a PR thread. > > > > I remember finding this one in the Spam dir (Gmail). It appears that > DMARC validation

[PHP-DEV] messages not delivering?

Hi, I'm think this problem might've cropped up again. I didn't receive this message: http://news.php.net/php.internals/99052 I only heard about it because it was mentioned in a PR thread. Similarly, I'm wondering if some messages in this thread weren't getting delivered: http://news.php.net/php.

Re: [PHP-DEV] Re: [VOTE] PDO Float Type

> > > I had a request on the PR[1] to rename the const, from PDO::PARAM_FLT to > > PDO::PARAM_FLOAT. Agree that readability is better here. Since there's > been > > a change, I'll plan on opening the vote tomorrow. > > Are you kidding me? > You can't possibly think that changing the constant name

[PHP-DEV] [RFC] deprecate PDO::PARAM_NULL

Hi, I've heard a few people here mention that this type isn't useful. It looks like it wouldn't be harmful to remove. The RFC mainly outlines the impact and proposes a schedule for doing so. https://wiki.php.net/rfc/deprecate_pdo_null Please let me know your thoughts. Thanks, Adam

[PHP-DEV] Re: [VOTE] PDO Float Type

> > I took another pass at this RFC: >> *https://wiki.php.net/rfc/pdo_float_type >> * >> > > Unless discussion prompts major changes, I'll open this for a vote next > Monday. > I had a request on the PR[1] to rename the const, from PDO::PARAM_FLT to PDO::PA

Re: [PHP-DEV] Re: [VOTE] PDO Float Type

Hi, Thanks for the feedback. I voted "no" because for very little improvement (which really isn't worth > it) > It would help me to understand why you think this. It's difficult to generate queries with the best execution plans if the type information isn't good. Floating point values are part o

[PHP-DEV] Re: [VOTE] PDO Float Type

Hi, I took another pass at this RFC: > *https://wiki.php.net/rfc/pdo_float_type > * > Unless discussion prompts major changes, I'll open this for a vote next Monday. Thanks, Adam

[PHP-DEV] Re: [VOTE] PDO Float Type

Hi, I took another pass at this RFC: *https://wiki.php.net/rfc/pdo_float_type * Most of the discussion in the last round was about fixed precision types. Since there was a lot of disagreement around the right way to handle them, I'd like to keep them out o

[PHP-DEV] JS error on PR tool

Hi, I'm getting a JS error that's preventing this page from loading completely: https://qa.php.net/pulls/ The error is: Uncaught TypeError: Cannot read property 'msie' of undefined (jquery.ba-bbq.min.js:18) Is anyone able to take a look at this? Thanks, Adam

[PHP-DEV] Re: [VOTE] PDO Float Type

> > I'd like to open the vote on this RFC: > *https://wiki.php.net/rfc/pdo_float_type > * > > Previous discussion: > *https://externals.io/thread/805 * > > Voting will end on the 26th at 0:00 UTC. > The RFC was rejected by a

Re: [PHP-DEV] [RFC] PDO Float Type

> > On 20/04/2017 00:51, Adam Baratz wrote: > > The reason I went that way was I couldn't find a DB API that > > differentiates between the two types. They all represent them as a > > double, so it seemed like a needless distinction to create two PDO > > types,

Re: [PHP-DEV] [RFC] PDO Float Type

> > I apologise if I've been harsh, but I am truly disappointed. I tried to > sway the RFC in a certain direction, that is conveying the pretty basic > notion that using floating points for fixed precision numbers is wrong: > there's lots of literature on that and especially why floats shouldn't >

Re: [PHP-DEV] [RFC] PDO Float Type

Hi, Thanks for allowing everyone the time to look at the RFC changes before > opening the vote ;) > I didn't think I needed to extend discussion for the changes I made. The substance of the proposal hasn't changed. I just responded to your criticism that there'd need to be a separate type for fix

[PHP-DEV] [VOTE] PDO Float Type

Hi, I'd like to open the vote on this RFC: *https://wiki.php.net/rfc/pdo_float_type * Previous discussion: *https://externals.io/thread/805 * Voting will end on the 26th at 0:00 UTC. Thanks, Adam

Re: [PHP-DEV] [RFC] PDO Float Type

> > > I'd be most comfortable with this approach. I'd worry about adding a > > PDO::PARAM_NUMERIC type without investigating how it needs to function > for > > each DB, which feels like scope creep. If it starts off as an alias for > > PDO::PARAM_STR, there could be issues updating it to work corre

Re: [PHP-DEV] [RFC] PDO Float Type

> > > I'd suggest adding a warning to the manual instead. > > I think that's a requirement in any case. I'd be most comfortable with this approach. I'd worry about adding a PDO::PARAM_NUMERIC type without investigating how it needs to function for each DB, which feels like scope creep. If it star

Re: [PHP-DEV] [RFC] PDO Float Type

> > That said, I think the proposed type is likely to be misused for > NUMERIC/DECIMAL fields, which would be pretty bad. Maybe we should also > add PDO::PARAM_NUMERIC in order to avoid mistakes? > Just so I understand your concern, it's that fixed-precision types are meaningfully different and th

[PHP-DEV] [RFC] PDO Float Type

Hi, The PDO extension does not have a type to represent floating point values. The current recommended practice is to use PDO::PARAM_STR. I had poked at this topic in an earlier thread: https://externals.io/thread/551 There was some hesitation about how complicated this would be to implement. Af

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

> > > 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 >

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

> > 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 feedbac

Re: [PHP-DEV] Let range() return a generator?

> Yes, that's a BC break. Instead of changing it, there could be a new > function. But as it can be simply built in userland, I don't see much > reason to have it in core. Whether or not it's in core, the two-pronged approach is what Python does (range and xrange). Sometimes you want an array and

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

> > 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 s

Re: [PHP-DEV] Proposing a new 'cache_key' streams operation

> > This PR creates a mechanism to be used by opcode caches to determine > whether a stream-wrapped URI is cacheable, and the key to use when > caching it. > Thanks for sharing this. Very interesting idea. Have you posted an RFC yet? That'll help lay out the bigger questions and guide the conversa

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

> > 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

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

Hi, I'd like to open the vote on this RFC: https://wiki.php.net/rfc/extended-string-types-for-pdo Previous discussion: https://externals.io/thread/715 Voting will end on the 17th at 0:00 UTC. Thanks, Adam

[PHP-DEV] generating code from AST

I'm exploring how to automate some basic kinds of refactor operations. One approach I'm considering: - Generate an AST - Rearrange it as needed - Turn it back into userland code Is this something anyone's explored? Thanks, Adam

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

> > 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 edg

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

> > 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

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

> > 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 gene

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

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 > c

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

> > 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 beli

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

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

Re: [PHP-DEV] writing extensions best practice, pass an object as parameter

> > but how can i pass the object from a private method of the PHP extension > class to the setcallbackfunction as it is down in PHP with > > array(&$this, '_htmlentities') > I usually find reading the source for standard library functions to be helpful for learning how to do things. array_map co

Re: [PHP-DEV] Dorin Marcoci Added Firebrid native type mapping for integers (smallint, integer, bigint) in PDO_Firebird driver

> > Unfortunately with current PDO state this is not possible to be done in a > nice way. > Now PDO have defined just these field types: PDO::PARAM_BOOL, > PDO::PARAM_INT, PDO::PARAM_STR, PDO::PARAM_LOB, PDO::PARAM_NULL. > Last one is “wrong” and should be removed. NULL is a state, not a type or >

Re: [PHP-DEV] Dorin Marcoci Added Firebrid native type mapping for integers (smallint, integer, bigint) in PDO_Firebird driver

> > Firebrid > native type mapping for integers (smallint, integer, bigint) in > PDO_Firebird driver It looks like this is an "always on" feature. There's a PDO attribute, PDO::ATTR_STRINGIFY_FETCHES, that's intended to allow toggling. Since this

Re: [PHP-DEV] Re: [RFC] ServerRequest and ServerResponse objects

> > Today marks two weeks since this RFC was introduced. As I said at the > start, it's the holidays, so I expect to keep the discussion period open > for longer than two weeks, but I am surprised at how little discussion > there has been. The email introducing the RFC missed my inbox somehow. I

[PHP-DEV] Re: [VOTE] Debugging PDO Prepared Statement Emulation v2

> > A little over two weeks have passed since posting this RFC: > https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2 > > There's been some discussion on this list: > http://marc.info/?l=php-internals&m=148034706404511&w=2 > > Discussion has cooled off, so I'd like to open to a v

Re: [PHP-DEV] PDO::PARAM_DOUBLE

> > For decimal, double wouldn't be the correct type anyway, as it could > cause loss of precision. > Sure, agree the name is imprecise. "Double" is mainly relevant to zvals. > Is there a reason PDO::PARAM_DOUBLE doesn't exist? > > I don't know if there's am historical reason. I think it should b

[PHP-DEV] PDO::PARAM_DOUBLE

If you want to bind a double to a statement, the accepted approach is to bind as a string: http://stackoverflow.com/questions/2718628/pdoparam-for-type-decimal However, this means that prepared statements see these values as strings. This can cause issues, for example: http://stackoverflow.com/que

[PHP-DEV] [VOTE] Debugging PDO Prepared Statement Emulation v2

Hi, A little over two weeks have passed since posting this RFC: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2 There's been some discussion on this list: http://marc.info/?l=php-internals&m=148034706404511&w=2 Discussion has cooled off, so I'd like to open to a vote. Voti

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

> > This issue is not difficult to solve in userland, at least well enough for > debugging in my experience. Here's an older example I wrote up on my blog > that worked (but I'm told is broken right now): https://daveyshafik.com/ > archives/605-debugging-pdo-prepared-statements.html > I want to be

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

> > Could you please explain what's the use case? As far as I'm concerned >> such information would only be useful during PDO driver development, >> phpt files and bug reporting / fixing. >> > > It's pretty simple : debugging and optimizing scripts and statements. I've > lost hours, manually emulat

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

> > Could you please revert? Albeit minor, it's a new feature and therefore > it belongs to 7.2. No problem. Reverted.

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

> > I'll incorporate it, and the content of this subthread, in the RFC when I > get my next free five minutes. :) > Done. And because of the scope of the v2 implementation, I changed the target release to next 7.1.x. Thanks, Adam

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

Hi, > Basically, you'd never see this kind of example: > > > > SQL: "SELECT * FROM tbl WHERE x = ?" > >> Sent SQL: "SELECT * FROM tbl WHERE x = $1" > >> > > why not? That's what active_query_string contains e.g. in pdo_pgsql w/o > emulate prepares. Which is more or less what has been sent to the >

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

Hi, I would not use "Parsed SQL" though, as it's not just the result of > parsing. In fact it could effectively be what has been sent to the backend, > regardless of statement emulation... > I'd be happy to make the feature more specific. The "Parsed" line would only show with emulated prepares e

[PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

Hi, > Based on my second thoughts on my initial approach, I created an RFC to > supplant it: > https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2 > I'd appreciate any feedback on this RFC, especially from any of the people who voted against the original[1]. Thanks, Adam ---

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

> > The minimum number of votes is going to be the subject of another RFC, >> let's leave that aside for now. >> > > I'm not sure splitting this into lots of micro-decisions is wise: why not > discuss a general reform of the voting system, and have a single RFC which > can then document the agreed

[PHP-DEV] [RFC] Debugging PDO Prepared Statement Emulation v2

Hi, Based on my second thoughts on my initial approach, I created an RFC to supplant it: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2 I believe this better addresses the negative feedback from the original RFC[1] and is a better solution to the problem. Thanks, Adam --

Re: [PHP-DEV] [VOTE] Debugging PDO Prepared Statement Emulation

> > Once the proposal had been accepted, and merged, it's not really > legitimate to unilaterally decide that it's a bad implementation and revert > it yourself. > That's fair. I will revert the revert and open a new RFC to supersede the previous one. Thanks again for your patience. Adam

[PHP-DEV] [VOTE] Debugging PDO Prepared Statement Emulation

Hi, No, you're not misreading the subject line. I began working on the docs for the previously accepted proposal and became uncomfortable with the approach. I think it will be better to integrate this info into PDOStatement::debugDumpParams(). It will let me do the testing I want to do without int

[PHP-DEV] [ACCEPTED] Debugging PDO Prepared Statement Emulation

Hi, This RFC reached the 50%+1 vote needed for acceptance: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation The implementation was added to master (PHP 7.2): https://github.com/php/php-src/commit/83086d9a72675bad2b2560c6f427d0c1f1d1eba0 Thanks, Adam

[PHP-DEV] [VOTE] Debugging PDO Prepared Statement Emulation

Hi, Two weeks have passed since posting this RFC: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation There's been some discussion on this list: http://marc.info/?l=php-internals&m=147638162506291&w=2 http://marc.info/?l=php-internals&m=147734024403899&w=2 http://marc.info/?l=php-

Re: [PHP-DEV] [RFC] Debugging PDO Prepared Statement Emulation

> > There's value in improving tests for emulated prepares, but as I stated > somewhere else, I would rather see them deprecated and removed rather > than encouraged. > I left a note about this in the "Future Scope" section[1]. If we deprecate emulated prepares, it would make sense to deprecate PD

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation

> > > My point is that you are adding 'testing tools' which are only any use > > to test themselves and not the actual interface? It's creating > > additional code that has nothing to do with testing that PDO is working > > cleanly properly across all databases, especially if it does not expect > >

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation

> My point is that you are adding 'testing tools' which are only any use > to test themselves and not the actual interface? It's creating > additional code that has nothing to do with testing that PDO is working > cleanly properly across all databases, especially if it does not expect > a working c

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation

> > Since PDO is an interface to third party databases this seems totally > out of place in PHP. Prepared statements are a sensible mechanism for > for anyone wanting secure access to those database, so what is the point > of this code. I don't want to solve for database access. I want to create

[PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation

> > I've created an RFC to make it easier to work with emulated prepared > statements: > https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation > Does anyone have feedback?

Re: [PHP-DEV] [RFC] Driver-Specific PDO Param Types

On Wed, Oct 19, 2016 at 12:25 PM, Lester Caine wrote: > On 18/10/16 23:05, Adam Baratz wrote: > > Please share your feedback. I'm happy to hear thoughts about the > pdo_dblib > > example, but the RFC is more about the possibility of driver-specific > types > > tha

[PHP-DEV] [RFC] Driver-Specific PDO Param Types

Hi, I've created an RFC to change how types are defined in PDO: https://wiki.php.net/rfc/driver-specific-pdo-param-types Please share your feedback. I'm happy to hear thoughts about the pdo_dblib example, but the RFC is more about the possibility of driver-specific types than these particular one

[PHP-DEV] [RFC] Debugging PDO Prepared Statement Emulation

Hi, I've created an RFC to make it easier to work with emulated prepared statements: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation Based on feedback from a previous thread[1], I added some context and added two other potential solutions to the problem. Please share your feed

[PHP-DEV] PDOStatement::activeQueryString()

Hi, I'd like to add a new method that would return the prepared statement as it was executed. It's common for people I work with to want this info for debugging, but you can't get it from userland. The functionality is similar to, but distinct from PDOStatement::debugDumpParams(). I figure it's a

Re: [PHP-DEV] Fwd: [PHP-BUG] Bug #73234 [NEW]: emulated statementslet value dictate parameter type

On Wed, Oct 12, 2016 at 4:58 AM, Rowan Collins wrote: > On 11/10/2016 17:39, Lester Caine wrote: > >> The importance of 'null' in relation to SQL data sets is something that >> PHP seems to push under the carpet a bit. It is essential to the way SQL >> works and so needs to mirror properly which

Re: [PHP-DEV] Fwd: [PHP-BUG] Bug #73234 [NEW]: emulated statementslet value dictate parameter type

> > I've had a quick look at the bug fix, although I haven't tested it. By > the looks of it, it seems that the third parameter has become mandatory, > which to me seems unacceptable. > > I would say that the type parameter should have precedence over the > actual PHP type only when it is explicitl

Re: [PHP-DEV] Fwd: [PHP-BUG] Bug #73234 [NEW]: emulated statementslet value dictate parameter type

> > > Well, I'm pretty sure Postgres won't be affected either way, because > >>> its type system is such that you can't prepare a query where the types > of > >>> parameters can't be decided yet. A query like this simply gives an > error. > > Firebird, oracle and mysql would have exac

Re: [PHP-DEV] Fwd: [PHP-BUG] Bug #73234 [NEW]: emulated statementslet value dictate parameter type

> > >> Well, I'm pretty sure Postgres won't be affected either way, because > its type system is such that you can't prepare a query where the types of > parameters can't be decided yet. A query like this simply gives an error. > > > > Firebird, oracle and mysql would have exactly the same problem.

[PHP-DEV] Fwd: [PHP-BUG] Bug #73234 [NEW]: emulated statements let value dictate parameter type

This is a problem I've run into with pdo_dblib, but the fix would involve touching PDO Core. I'd appreciate any feedback on potential negative interactions with other drivers, as well as which PHP version I should target the fix for. It's arguable whether this is a bug or a feature request. If I do

[PHP-DEV] Re: pdo_dblib on pecl

On Tue, Sep 13, 2016 at 10:54 AM, Adam Baratz wrote: > > I noticed that there's a stale version of a supported package on pecl: >> > https://pecl.php.net/package/pdo_dblib >> > >> > Should this be removed to avoid confusion? >> >> Alternativ

[PHP-DEV] Re: pdo_dblib on pecl

> > > I noticed that there's a stale version of a supported package on pecl: > > https://pecl.php.net/package/pdo_dblib > > > > Should this be removed to avoid confusion? > > Alternatively a note might be added, as it has been done for > PECL/domxml, for instance. > > Either way, that should also b

[PHP-DEV] pdo_dblib on pecl

Hi, I noticed that there's a stale version of a supported package on pecl: https://pecl.php.net/package/pdo_dblib Should this be removed to avoid confusion? Thanks, Adam

RE: [PHP-DEV] merged branches in incorrect order

> To keep it clean, you can > > git checkout master > git reset --hard origin/master > > and same for every branch containing a wrong merge. This will reset every branch to the state of remote, after that you can repeat the merge clean way. Yes, but in this case, I'd already pushed.

[PHP-DEV] merged branches in incorrect order

I was following https://wiki.php.net/vcs/gitworkflow to make my first commit to ext/pdo_dblib. I made a little mistake. I committed first to PHP-7.0. I forgot about the PHP-7.1 branch and merged from PHP-7.0 to master. I went back and merged from PHP-7.0 to PHP-7.1. All merges applied cleanly, but

Re: [PHP-DEV] Re: VCS Account Request: adambaratz

> > I've granted you with ext/pdo_dblib karma, it takes a couple of hours to > propagate, let me know if you need further help. > Thanks! Is it also possible to get access to ext/pdo? I needed to add some conditional logic to get the shared tests running with pdo_dblib, but I can put up a regular

Re: [PHP-DEV] VCS Account Request: adambaratz

> > > One note I missed: it probably goes without saying that I'd like write > > access to ext/pdo_dblib, but write access to ext/pdo would also help for > > work on common unit tests and functionality. > > +1, Adam have done great work at trying to keep pdo_dblib alive, and I > think Anatol (cc'ed

Re: [PHP-DEV] VCS Account Request: adambaratz

One note I missed: it probably goes without saying that I'd like write access to ext/pdo_dblib, but write access to ext/pdo would also help for work on common unit tests and functionality. On Tue, Aug 30, 2016 at 4:00 PM, Adam Baratz wrote: > Maintain pdo_dblib extension. > &

Re: [PHP-DEV] request for pdo_dblib maintainer status

> Do you already have a git account? If not, you should request one on http://php.net/git-php.php. Didn't know about that. Just did, thanks.

[PHP-DEV] VCS Account Request: adambaratz

Maintain pdo_dblib extension. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] request for pdo_dblib maintainer status

Anatol suggested I reach out to this group. I've been doing some of this work in an informal capacity over the past few months (design/coding/testing feedback on relevant PRs). I'd like to take on the role officially. Besides the PR feedback, I'm working on improving the test suite so it can be run

Re: [PHP-DEV] [RFC] orphan extensions cleanup

> > pdo_dblib > I have seen a few PRs here and there recently from two different guys, > perhaps one of them would be interested in maintaining this as there > this is the only way to connect to MSSQL from PHP (if you dislike > odbc) as of PHP7, with the removal of ext/mssql. As one of those two

[PHP-DEV] automating gcov with third-party extensions

I had a positive experience using gcov with a C extension. I used it to get a better sense of what the .phpt tests (and valgrind) were really telling me. To get it to work in an automated way, I hacked out Makefile.gcov and some relevant chunks of config.m4 from php-src. I'm wondering if there wou

[PHP-DEV] reused hash tables in large data structures in PHP7

Hi, I've encountered a hard-to-consistently-reproduce issue with HashTable zvals. I have code that will generate big nested \stdClass structures for JSON encoding. It does so using classes that have methods that generate those fields. For example, you could have a class like this: class Block {

[PHP-DEV] writing .phpt tests against IS_INDIRECT values

I'm contributing to an extension -- https://github.com/jbboehr/php-mustache -- and part of that has been little fixes for PHP7. I posted a PR to fix how it was handling zvals that came in as IS_INDIRECT. The maintainer asked if I could extend the .phpt coverage accordingly. The reading I've done ha

Re: [PHP-DEV] segfault in ini_lex() in 7.0.3

> > If you haven't already done so, please file a bug report. The files > uploaded aren't very helpful in terms of diagnosing the issue. > I've dug a little deeper into this. Haven't isolated exactly where the problem's coming from, but I know enough to say the segfault I shared is a side effect

Re: [PHP-DEV] segfault in ini_lex() in 7.0.3

> > Can you provide the INI (minus secure info) and script that generates > this? Unfortunately, I haven't been able to isolate what's causing this. It seems to occur on "complex enough" pages. Which could mean one of the (many) extensions involved isn't playing nice with PHP7, which I'll look in

[PHP-DEV] segfault in ini_lex() in 7.0.3

I got a core dump with this output: Cannot access memory at address 0x9 Cannot access memory at address 0x1 #0 0x00654a6d in ini_lex (ini_lval=0xd314c15417d73c46) at Zend/zend_ini_scanner.c:3724 #1 0x0067da19 in init_executor () at /wayfair/home/cmccoy/rpmbuild/BUILD/php

Re: [PHP-DEV] pdo_dblib pull requests

> > I think the best way would be to try and provide tests (part of the PR) > and test environment for this change. > > If the latter can't be provided, maybe instructions how to create one (as > you guys probably have far more experience then us). I'll certainly provide tests. Maybe this vagrant

[PHP-DEV] pdo_dblib pull requests

Hi, I work for the rare company that uses Linux PHP servers with MSSQL. We rely quite a bit on this extension and have invested a little in some feature improvements. I'd like to get them pushed upstream, but given the relatively low usage of this extension, it seems like PRs easily get stuck in l

Re: [PHP-DEV] call_user_function_ex() affects zval value

> > If your code is public, can you give a pointer to the problematic call ? > Or at least what your 'zval' points to on return. > It's the PECL memcache extension: https://pecl.php.net/package/memcache All of the existing test suite passes, except for this one: http://git.php.net/?p=pecl/caching

[PHP-DEV] call_user_function_ex() affects zval value

Hi, I'm working on PHP7 compatibility for an extension (which I didn't write). I discovered an issue with a call like this: call_user_function_ex(EG(function_table), NULL, zval, &retval, 5, params, 0, NULL); When zval refers to a [object, string] array, its value is different after this call. I

  1   2   >