Re: [PHP-DEV] Apply strict_types to internal functions

I accidentally wrote the name in Japanese and it looks weird, so I'll resend it, sorry. I also skimmed over past discussions. I've found that having full control over `strict_types` globally is not a good idea. This is because it can break the behavior of many libraries, and developers don't

Re: [PHP-DEV] Apply strict_types to internal functions

> Just to be really clear, it is not true that internal functions "ignore" the > setting; they behave exactly the same as any userland function which was > *declared* in strict_types=0 mode. I see, I thought I understood, but it seems I was missing this point of view. If there is a change, it

Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

Does anyone have any opinions regarding this matter? If there is no response after waiting for a certain period of time, I will start preparing an RFC. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

> However, if we are going to remove it, it would be nice to have this done > consistently across all bundled extensions. Thank you for confirmation. This is probably not technically difficult, but it does increase the scope of change. However, as you say, the specifications should be unified.

[PHP-DEV] adding serialize_precision's value that uses mode2 and long double

Hi, internals. I had incorrect knowledge the `serialize_precision` until recently. I knew that setting this to `-1` would use a `long double`, but I didn't know that the number of digits would not be `17`. I've looked through RFC related to this. https://wiki.php.net/rfc/precise_float_value

Re: [PHP-DEV] Apply strict_types to internal functions

> That might not be intuitive to you, but it follows directly from the > specified semantics: whether a function is called in `strict_types` mode or > not, depends only on where the function is called. I personally doubt that > there is an easy way to adjust the rule in order to make it both

Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

> We may get away with deprecating and removing PDO silent/warning mode because > it's an extension that was introduced in PHP 5 and everyone was on board with > using exception mode. We probably cannot remove silent mode for other > extensions that either mimic older extensions that didn't use

[PHP-DEV] [Round] Change the edge case of Round()

Hi, internals I'm working on fixing a bug in `round()`. There was a discussion about what should be considered an edge case. For example, `0.285` is internally `0.28498`. Should this be considered an edge case? Or is it not an edge case? Regarding this issue, in 2008, the

Re: [PHP-DEV] Two new functions array_first() and array_last()

Hi Pierre > The first two probably only make sense for a numerically indexed array I do not think so. If these are something like "reset/end without side effects", then they should work fine even not numeric indexed array. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List

Re: [PHP-DEV] Change the signature of odbc_connect

Hi, Máté Thank you for your feedback! After seeing your email, I decided to start implementing it. I have already created a pull request for a bug fix that does not require a signature change, and I plan to update it. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To

[PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

Hi internals, As shown in the following issue, the behavior of `PDO::PARAM_` is inconsistent and I would like to fix this. https://github.com/php/php-src/issues/12603 First, I tried fixed pdo_pgsql. https://github.com/php/php-src/pull/12605 Eventually I plan to make similar changes to all

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

I couldn't express myself well in English, I'm sure my words were bad. sorry. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

I should have said that the spec was broken, not the code. By that logic, my PR is probably broken as well. I did additional research on each DB to see if the specs were broken. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, It's been two weeks since then. I don't think there is any reason to prevent enhancements to BCMath's functionality at this point, unless there is a realistic discussion of deprecating BCMath and providing another math extension. Also, regarding conflicts with functions of the same name

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

Hi, To think more deeply about this issue, I investigated various cases in major databases. It's too big to write in an email, so I posted it in the comments of the issue. https://github.com/php/php-src/issues/12603#issuecomment-1793679776 Regards. Saki -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

Hi Matteo, > I'm sure there are several bugs w/ types in PDO. > > Perhaps some can be fixed, but I would be very careful touching that part. > > The last time I tried to fix the PDO_PARAM_INT behaviour on pdo_pgsql I broke > Laravel and surely many other projects. > > I'm afraid that most

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi, It's almost been two weeks since I opened this discussion. If there are no other opinions, I am thinking of starting a vote tomorrow or later. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi Mike, I'm still new to RFC and your advice would be very helpful. I have added as much of the rationale for the changes as I can think of to the RFC. I would be happy if you could see it again. Thank you, regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi Jakub, > please do not top post - you might want to check these rules for PHP mailing > lists: https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md > if you haven't seen them already ;) I intended to post with all the quotes deleted, but it seems I was wrong. > It would be

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi Tim, > I think, most often, round() is done on the result of some calculation, not > on decimal literals. The previous implementation seems to prioritize rounding > of decimal literals over correct rounding of the actual value. Yes, as Jakub pointed out, there was a lack of explanation

Re: [PHP-DEV] New DateTime[Immutable]::createFromTimestamp

Hi, Rowan I may have been thinking a little too much on the "technical side". Admittedly, my concern is in rare cases. OK, I understood that the problem is unlikely to occur in a realistic use case. Now, I'll just quietly watch this discussion. Regards. Saki -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Basic Type Alias

Hi, It seems to me that there is more to lose than gain. I'm afraid that when we look at the signature, we'll be confused as to whether it's a class or a type. Even if these problems were successfully resolved, I feel that it would only reduce readability. I've never seen a union type complex

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

Hi Hans, > I think it'd be a good idea if they used FILTER_VALIDATE_BOOLEAN and > FILTER_VALIDATE_INTEGER type logic, with an error if conversion fails.. This can be difficult. Forcing an error is highly likely to destroy the existing user environment. > I wonder if PDO::PARAM_BOOL_OR_NULL

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi Claude, > Reading the RFC, it is unclear for me what are the benefits of the change, > and whether it is worth the subtle breaking of existing code that implicitly > relies on the current behaviour. “FP is just FP” looks like an ideal > position, and one that has a counteragument given in

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

As Ayesh says, I'm starting to feel like I need to provide a completely new feature separately tbh… The following issues are completely bugs and should at least be fixed. https://github.com/php/php-src/issues/12581 Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

Hi, I think this is probably the same problem that Matteo ran into, but when using emulate mode, pgsql errors out with code like this: ``` true, ], ); $db->exec('CREATE TABLE test2 (val BOOLEAN)'); $stmt = $db->prepare('INSERT INTO test2 VALUES(:val)'); $stmt->bindValue(':val', 1,

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

Hi Kentaro, The case you presented certainly confuses us very much. Although it is outside the scope of this discussion, it certainly seems like it would be better to improve it from a safety perspective. BOOL probably has the most problems; for example, when you pass str, the boolean value

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

Hi, Ayesh, I forgot to tell you one important thing. Binding of parameters is not actually done in the `bind`method, but in the `execute()` method. Therefore, when preparing a new method, a slightly larger mechanism is required to determine which method the parameter was set through.

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

Hi Hans, Thank you, I will discuss it and improve it in a way that everyone is satisfied with. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] New DateTime[Immutable]::createFromTimestamp

Hi Marc, Personally, I don't think these are necessarily necessary since there is a "from format". However, there is certainly an issue of convenience, so I'm not against it if there's a demand for it. I have one concern. float is imprecise, so I don't think it's suitable for this kind of

Re: [PHP-DEV] New DateTime[Immutable]::createFromTimestamp

Hi Rowan, > I'm not sure where you got those numbers; on a 64-bit architecture (surely > the vast majority of PHP installs), a float can precisely represent any whole > number from -2**53 up to 2**53 - 1. As a Unix timestamp, that's a one-second > accuracy for any time 285 million years into

Re: [PHP-DEV] New DateTime[Immutable]::createFromTimestamp

Hi Marc, > On a 64bit system it's obvious to have higher precision if you handle the > integer and fractions part separately (as timelib does) but this doesn't help > if you already have a floating point number at hand. Also JS uses a double > float for timestamps in milliseconds which is the

Re: [PHP-DEV] Issue with php.net

Hi, The issue has opened here. https://github.com/php/web-php/issues/820 Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

> What about a signature like: > > ```php > array_first(array $array, mixed $value_if_missing = null); > ``` > > That would let you specify your own sentinel (or default) where appropriate, > without losing the convenience of this function. This is a problem that should be addressed in your

Re: [PHP-DEV] Final anonymous classes

Hi, Daniil > Personally, I would have instead preferred the much cleaner approach of > making *all* anonymous classes final by default, (preferrably) without > offering the option to make them non-final. > > However, I understand that this might be a little bit too restrictive for > something

Re: [PHP-DEV] Two new functions array_first() and array_last()

I see now, that makes sense. There is also a technique to make the return value `[$key => $value]` instead of just a value, but this loses simplicity. Thanks. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] adding serialize_precision's value that uses mode2 and long double

Sorry, please forget… I must have been very sleepy… Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int

Hi, Marc. > All of these functions already take an `int|float` and therefore the setting > of `strict_types` is irrelevant here on passing float vs. int. Oops, excuse me, I completely misunderstood the signature. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

[PHP-DEV] What should I do to create an RFC?

Hi. I want to create an RFC. This is my first time. The next two pages each have sections on how to create RFCs. However, they differ slightly in content. Which way should I use? https://wiki.php.net/rfc/howto https://wiki.php.net/rfc/voting I already have a wiki account. Is requesting karma

Re: [PHP-DEV] trim support for multibyte spaces

> I also want to trim function of multibyte trim functions. > I think that in addition to mb_trim, mb_ltrim and mb_rtrim are also necessary. Hi. Having a new option besides regex sounds like a good idea for me, as a user of a language that benefits from `mb_trim()`. Perhaps users are more

Re: [PHP-DEV] What should I do to create an RFC?

> You should follow this one ^. It contains a step by step guide on what to do. > >> https://wiki.php.net/rfc/voting > > This document was an RFC on its own to establish the rules around voting. > Yes, you should ask for RFC karma. > I suppose your initial email is sufficient to get that. It

Re: [PHP-DEV] Add bcround, bcfloor, bcceil to BCMath.

Hi, George. > I think regardless of the issues around round(), ceil(), floor(), etc. > having the equivalent functions for BCMath makes a lot of sense to me. I'm relieved to receive positive feedback. I'll start writing the RFC. There is no doubt that the idea came from the `round()` problem,

Re: [PHP-DEV] What should I do to create an RFC?

Hi, Ilija > I've granted you RFC karma. Good luck! Thank you! I start writing an RFC. Once completed, I’ll send an email as a new thread. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, internals I would like to start the discussion for my RFC "Adding bcround, bcfloor and bcceil to BCMath”. https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, Claude, Jorg > If the existence of the function is checked in advance, the BC risk is worst, > because they cannot have known whether the signature and semantics of the > function you will introduce will be compatible with the one they have > defined. In case of mismatch the eventual

Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int

Hi, Marc. There is one additional case to consider. It's backwards compatible. If `strict_types` is not `1`, the code currently out there may be passing `int` to these functions. Therefore, it is better to be aware that such code can have destructive effects, and to consider whether or not to

[PHP-DEV] Add bcround, bcfloor, bcceil to BCMath.

Hi, internals. I'm currently working on renovating the `round()` function. The current `round()` function rounds a value like 0.285 (0.28499) to 0.29 using pre-round. This is a mistake for FP, so discussions are underway to abolish such pre-round behavior. However, there is definitely a

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, Marc, Pierre Thank you for all the information. After all, I feel that BCMath and GMP have different roles. Arbitrary precision mathematics and very high precision mathematics are similar but distinctly different. If PHP has already started integrating these things, then of course I'll

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

> yes, they do, as do almost all floating points implementation. > > Memory limited float values and their respective operations are still useful > in many areas, but financial values and the likes. Scaled integers are the > way for accuracy. > > > Also, side note, gmp recommends to rely on

[PHP-DEV] Change the signature of odbc_connect

Hi, internals I'm currently working on renovating odbc_connect and odbc_pconnect. https://github.com/php/php-src/pull/12306 As a problem came up, I'm planning to create an RFC. I explain the problem briefly. In addition to the dsn, these functions have a credential argument. They are

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, Jordan Thank you, that was an easy to understand explanation. I would agree with that, if it means creating new math features that aren't currently bundled, rather than unifying them with GMP. How far along is this plan now? I'm very interested in that. Regards. Saki -- PHP Internals -

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Should we use MPFR for new mathematics? I'm not very familiar with it, but am I correct in understanding that this can definitely represent a decimal number correctly, albeit a floating point number? Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, Pierre In fact, I predict that many use cases will be covered by GMP. Still, I think that there may be cases where calculation functions like mainframe BCD are required, such as when calculating money. I am unable to decide whether it is correct to deprecate BCMath and only use GMP. I'd

Re: [PHP-DEV] Two new functions array_first() and array_last()

Since reset() and end() return false when the array is empty, in a sense, there is an idea that there is no need to take such strict care of the return value. If you were to take proper care, you would probably specify a default value or throw an exception, as has already been suggested.

Re: [PHP-DEV] Two new functions array_first() and array_last()

I thought of it after sending the email, so I'll post it again. By combining my two ideas, I think I can come up with a smarter proposal. ``` array_first(array $array, int|string &$key = null) ``` If you want to accurately determine whether an array is empty or not, you can satisfy your

Re: [PHP-DEV] Change the signature of odbc_connect

Hi Do you think this requires an RFC in the first place? If there are no objections after waiting for a while, I will submit a pull request without creating an RFC. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi, internals I would like to start the discussion for my RFC "Change the edge case of round()”. https://wiki.php.net/rfc/change_the_edge_case_of_round Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Sorry, I posted a completely unrelated URL. Correct url: https://wiki.php.net/rfc/change_the_edge_case_of_round Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Constructor promoted property and default value

Hi, Pierre You may have overlooked the existence of the magic method `__unserialize()`. Constructor is not the only way to create instances. When rebuilding a serialized object, you may need the initial values ​​of properties. This can easily happen if you are using rolling updates and using

Re: [PHP-DEV] Constructor promoted property and default value

> If I understand your use case properly, you should be confused by properties > with default values that are not constructor-promoted as well ? Am I wrong ? > In this case, your problem is not with promoted properties ? If we specify it the way you say, the initial values ​​of the constructor

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi, Max This was originally discussed in a pull request. If you're interested in the original discussion, check out this pull request. https://github.com/php/php-src/pull/12268 Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, Jeff Thanks for letting me know your use case. This is important information when discussing this issue. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, Claude I'm very sorry, I'm not a native English speaker and I couldn't quite understand whether you think BCMath should be integrated into GMP. I understand your use case well, so if you don't mind, can I ask if it should or should not be integrated? Regards. Saki -- PHP Internals - PHP

Re: [PHP-DEV] Two new functions array_first() and array_last()

Hi, David Many times I've seen reset() used to meet this requirement. I support this, not only from a side effect standpoint, but also from a readability standpoint. I would also like to add the opinion that it is better because it is simpler than the function name in the original RFC that is

Re: [PHP-DEV] Two new functions array_first() and array_last()

I came up with the idea of ​​using a signature like array_filter(), and when a callback is passed, "return the first/last element that matches the condition" and "return null if there is no match." The downside to this idea is the loss of simplicity. So I'll leave it up to you whether you want

[PHP-DEV] Apply strict_types to internal functions

Hello. I’m Saki Takamachi. Inspired by the issue below, I'm thinking of proposing this RFC. https://github.com/php/php-src/issues/12055 As the documentation below states, PHP's internal functions currently ignore strict_types. https://www.php.net/manual/en/language.types.declarations.php

Re: [PHP-DEV] Apply strict_types to internal functions

> Heya! > > I was not aware that strict types didn't work here. While I'm 100% behind > the idea, I am afraid that changing this will break code in currently > strict files where the assumption was made that it already worked like > that. It would probably have to give deprecation notices first,

Re: [PHP-DEV] Apply strict_types to internal functions

> Hi, > > The larger issue is that higher-order functions do not inherit the > `strict_types` mode from its calling code, and this is not specific to > internal functions. > > If you intend to change that for internal functions (with proper deprecation > period, of course), you might consider

[PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

Hi, internals. I thought about various things to improve the current situation where `PDO::ATTR_ERRMODE` is not working very smartly. Exceptions may be thrown regardless of the setting of `PDO::ATTR_ERRMODE`. https://www.php.net/manual/en/pdo.rollback.php#refsect1-pdo.rollback-errors Another

[PHP-DEV] Re: [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, The discussion seems to have calmed down, so I'll start voting at the beginning of next week. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi Jordan, > I think this makes much more sense if PHP programmers had internal access > to the float type in PHP, but that's not the case. You cannot choose > between float representations, you cannot easily examine the mantissa bits > directly. In the absence of stuff like that, I think the

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

I forgot to quote again. > It might make sense to also put some info what other languages / dbs do. For > example Python round(0.285, 2) result is 0.28 and it's got also decimal > parameter. If you can find other implementations that have got such function, > that would be great! Added

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi Jakub, Thank you for the advice! Added results for Ruby, Python, and major DBs. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi Kamil, > Why does this have to be done in PHP? Why can this not be done in SQL? Of course, we can also do it with SQL. Indeed, many frameworks do that. However, if we think about it from that perspective, functions such as `beginTransaction()` and `commit()` can also be executed with SQL,

[PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi internals, I'm thinking of adding a `savepoint(string $name)` method to PDO. Similarly, add `releaseSavepoint(string $name)` and change the signature of `rollback()` to `rollback(?string $name = null)`. Savepoint is a feature defined in SQL99, so it is a feature supported by many

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi Larry, > I like this proposal. It's a good incremental improvement to PDO. I also > agree with rollbackTo(), to avoid confusion. Thank you, I'm glad to receive your positive feedback. It is very difficult to implement these in pdo_odbc because the odbc API does not support savepoint.

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

> There's been discussion recently about how to deal with incompatibilities > between different PDO drivers, especially now that we can have subclasses per > driver. That may be the way to deal with it. I don't have a major opinion > on the approach, other than all incompatibilities should be

[PHP-DEV] VCS Account Request: saki

Perform PHP maintenance. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] `PDO::FETCH_CONSTRUCTOR` fetch mode proposal

Hi Frederik > First off, please excuse me if I’ve done something wrong related to the usage > of the mailing list. This all is completely new to me. Welcome to the internal mailing list! I had looked the pull request, and I'm pleased to have received your email promptly. > Thank you, the link

[PHP-DEV] Re: [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Please ignore the spelling mistakes Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Hi internals, The following code: ``` $db = new PDO(/* omission */, [PDO::ATTR_ATUOCOMMIT => 0]); $db->beginTransaction(); $db->setAttribute(PDO::ATTR_ATUOCOMMIT, 1); ``` The behavior in this case varies depending on the DB driver and is not unified. MySQL, OCI, ODBC, and Firebird currently

Re: [PHP-DEV] Re: [RFC] [VOTE] Adding bcround, bcfloor and bcceil to BCMath

Hi Tim, > The 14 days of voting are a *minimum* period. Anything substantially longer > would be unusual, but not disallowed. I misunderstood that it needed to be exactly 2 weeks. As you said, I will revert it back to the original date of the 30th. Regards. Saki -- PHP Internals - PHP

[PHP-DEV] [PDO] 2 phase commit

Hi internals, For the past few days I've been thinking about whether to make a suggestion to add two-phase commit functionality to pdo. I would like to hear everyone's opinions. About two-phase commit Regular transactions do not guarantee consistency across multiple DBs. For example, if you

Re: [PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Hi Ayesh, > Unfortunately it did not make it to PHP 8.3, but the RFC vote > indicates the trajectory everyone hopes to have in PDO. It was voted > yes unanimously, so there is definitely a preference in majority of us > to iron out the differences, but perhaps in a non-BC way, preferably > making

Re: [PHP-DEV] [RFC] [VOTE] Adding bcround, bcfloor and bcceil to BCMath

Hi internals, > I started voting on my RFC "Adding bcround, bcfloor and bcceil to BCMath”. > > Voting will end November 30th, 00:00 GMT. Voting has closed, and the addition of bcround, bcfloor, and bcceil to BCMath was unanimously approved (13:0). I will start creating PRs to implement these.

[PHP-DEV] [RFC] [VOTE] Change the edge case of round()

Hi internals, I started voting on my RFC "Change the edge case of round()”. Voting will end December 8th, 00:00 GMT. https://wiki.php.net/rfc/change_the_edge_case_of_round Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

[PHP-DEV] Re: [RFC] [VOTE] Adding bcround, bcfloor and bcceil to BCMath

Hi internals, > Voting will end November 30th, 00:00 GMT. I made a mistake in my calculation. It's until the 29th. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [PDO] 2 phase commit

Hi, > Do you have any ideas how to handle this case at the core level in the > regard of php lifecycle? I agree with Kentaro on this. This can be said to be a weakness of two-phase commit itself, but I think it should be addressed in userland or user operations. BTW, I said that I was

Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()

Hi all, Voting is now closed. As a result of the vote, this RFC was rejected. (7 in favor, 8 against) Therefore, as stated in the RFC, the following pull request will be adopted to fix the bug in `round()`. https://github.com/php/php-src/pull/12268 Thank you for all your votes. Regards.

Re: [PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Hi Matteo, > PDO's main goal was to make building db drivers easier, and it's not meant to > be a full DB abstraction layer. > > As such, it is not expected that all databases behave the same, especially > for exotic functionality, such as autocommit. As you say, such behavior varies from DB

Re: [PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

Hi, > In the latter case, I suppose they would expect the behaviour to be compliant > with the database standards. I may not have had this perspective. And this is a strong basis for explaining that different drivers behave differently. I will continue with the current implementation and

Re: [PHP-DEV] [PDO] 2 phase commit

Hi Jeff, > Would the implementation use the underlying RDBMS two-phase commit? Or would > the proposal be to try to build something at the PDO layer to mimic two-phase > commits? The former seems good, the latter, not so much. When implementing this, if each DB driver's API has a two-phase

Re: [PHP-DEV] [PDO] 2 phase commit

Hi Larry, > I have not heard of this functionality before, so I don't know how common it > is. If it's only lightly supported and in different ways, perhaps this is a > use case for the new per-DB subclasses? Many DBs have this functionality, so I was thinking of implementing it in the same

Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

Hi Kentaro, Thank you for your important point. > While most databases use `SAVEPOINT [name]`, but: > > https://github.com/laravel/framework/blob/v10.43.0/src/Illuminate/Database/Query/Grammars/SqlServerGrammar.php#L453-L456 > > ```php > return 'SAVE TRANSACTION '.$name; > ``` > > SQL Server

[PHP-DEV] [RFC] [VOTE] Adding bcround, bcfloor and bcceil to BCMath

Hi internals, I started voting on my RFC "Adding bcround, bcfloor and bcceil to BCMath”. Voting will end November 30th, 00:00 GMT. https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] Request PHP 8.3 GA release push back

> As far as I am aware, the 8.3.0 release is meant to be tagged tomorrow. > > However, there are at least three known bugs in RC6: > > - An ext/posix bug [1], which has a fix [2] > - Two ext/pgsql bugs around the new pipeline support: > - A constant not being exposed [3] > - The overall

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

Hi Jakub, I added and modified into the RFC. I would be happy if you could check it out. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Tim, > I don't see a change made, so perhaps I was unclear in what I said. What I > meant was: Please add a full stub example including all the interfaces, > properties, and methods. It's currently split across multiple code blocks and > the interfaces are missing entirely. > > Example: >

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Rowan, a). > I propose: > > - The constructor accepts string|int $num only. > > - All operations accept an optional scale and rounding mode. > > - If no rounding mode is provided, the default behaviour is to truncate. This > means that (new BCMath\Number('20'))->div(3, 5) has the same

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

postscript: The `precision` of `round()` can be negative. I'm not sure if this should be called `scale`. Regards. Saki

  1   2   >