Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

[BohwaZ]

> The ext/imap extension isn't going to disappear, it is not going be 
> unbundled as we can not guarantee the underlaying library is
> maintained. Not only is it no longer maintained, the original
> purveyors have removed any mention of it from their website.
> 
> For most people, there will be little change here. On Debian for 
> example, "php-" is used for both bundled and PECL'ed 
> extensions.

OK then :)

> Using Curl seems like a bad alternative, as it would likely have to
> open a connection for each action that you do.

No, curl is clever and keeping the connection open as long as you don't
use curl_close.

This is clearly visible when enabling verbose mode:

…
< A004 OK Fetch completed (0.001 + 0.000 secs).
* Connection #0 to host localhost left intact
* Found bundle for host localhost: 0x55d0b5c60f50 [serially]
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 143 (#0)
> A005 FETCH 1:* FULL
…

In my experience, using curl is much faster than using ext/imap :)

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

Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

[BohwaZ]

> Considering the lack of updates from upstream as Derick mentioned,
> lack of OAuth support (which webklex/php-imap supports), and a
> somewhat lackluster documentation for ext-imap in php.net, I think
> unbundling ext-imap (along with the other extensions in the proposal)
> makes sense.

I don't think that OAuth support is an argument, as most providers
don't support OAuth, so the imap package might still be relevant for
people who are not using Google.

Also, the package currently works, IMAP is a stable protocol, maybe
this library is just stable?

I'm not against the removal, but having to rely on user-space libraries
probably means we'll lose some performance over using the C library.

Also, some widely-used libraries like php-imap use it:
https://packagist.org/packages/php-imap/php-imap

Personally I'm using curl for IMAP, as it is more widely available, but
I think removing php-imap might be a bit too early, except if keeping
it does require a lot of time / effort?

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

Re: [PHP-DEV] Re: [PECL-DEV] PHP Servers SSL Certificate Expiry

[BohwaZ]

Hi Derick,

I've had the same kind of issue as you. So I set up a script that will
check every day if the certificate for my domains expires in more than
30 days and sends me a SMS if the check fails.

Here is the code of the certificate check part, if that may be useful:
https://gist.github.com/bohwaz/a3e4eb91e82f12768b69f8d24cf0cca8

Have a nice day :)

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

Re: [PHP-DEV] Security implications of parsing env variables in .ini

[BohwaZ]

This is a valid concern, as we are side-loading plugins in our
software, where plugin information is defined in a .ini file.

But somehow I thought that INI_SCANNER_TYPED was a bit like
INI_SCANNER_RAW but also able to handle null/true/false values.

Unfortunately it's not the case:

php > var_export(parse_ini_string("secret=\${AWS_SECRET_ACCESS_KEY}",
false, INI_SCANNER_TYPED)); array (
  'secret' => '42',
)

If you want to be able to have false/true/null values without expanding
variables and constants you are out of luck.

Maybe we should have another constant to be able to disable both
variable and constant expansion when using parse_ini_* functions, for
example:

parse_ini_file('file.ini', false,
  INI_SCANNER_TYPED & ~INI_SCANNER_EXPANSION);

Or something similar.

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

Re: [PHP-DEV] [VOTE] PDO subclasses

[BohwaZ]

I don't have voting rights, but just wanted to thank you again for your
work :)

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

Re: [PHP-DEV] PDO Subclasses coming to vote soon.

[BohwaZ]

> Yes?
> 
> I think you possibly misread my email.

Ah! sorry I understood the opposite, that you were wondering about
letting people load extensions from SQL. Great that we are on the same
note :)

> Sorry, I am in too much pain to look at those before the deadline.
> There is always 8.4 https://www.youtube.com/watch?v=wccRif2DaGs .

No worries, what you did is already awesome :) If I myself get any free
time I'll look at porting my code from the sqlite3 extension to PDO.

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

Re: [PHP-DEV] PDO Subclasses coming to vote soon.

[BohwaZ]

> As that means that SQLite extensions can only be loaded through C code
> (not through SQL), and if someone can upload and execute code to your
> server, your server is compromised anyway, having to edit ini files to
> enable extension loading, seems like a bad tradeoff.

I'm sorry to disagree, but changing this would be a bad idea for
security.

Imagine this scenario:

- user can execute SQL statements (that's the case in my app: users
  can execute read-only statements, this is by design)
- user can upload files

I'm quite sure that I never want users to be able to load any
extension through SQL, or it would mean trouble :(

Also, we have recently see malicious extensions able to escape SQLite3
and gain shell access... Sounds bad.

So just like in the SQLite3 extension, extension loading should be
limited to using the PHP method, not SQL. And we should be able to
restrict which extensions can be loaded, at the server level
(PHP_INI_SYSTEM), as in mass hosting we don't want hosted sites to be
able to load any extension.

For other points of the RFC:

- forcing to UTF8 is OK for me, I don't think anyone ever requested
  being able to do something different over the years for the SQLite3
  extension.

- it would be great to also have ::setAuthorizer in PDOSQLite :)

- same for ::backup :)

- not sure what would be the best for asserting if a statement is
  read-only, to get the same as SQLite3Stmt::readOnly(), maybe
  something like:
  PDOStatement::getAttribute(PDOSQLite::READ_ONLY_STATEMENT) ?

Thanks for your work and time! It's great to finally see some progress
on PDO and custom driver features :)

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

Re: [PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

[BohwaZ]

Voting has now ended with 21 votes for the "yes", and zero votes for
the "no".

Thanks everyone!

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

Re: [PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

[BohwaZ]

Hi Illia,

thank you for your feedback.

This is actually what I did, first, but I changed after feedback from
@Girgias:

https://github.com/php/php-src/pull/11058#discussion_r1162723112

> You are likely to get push back not just from myself if you propose
> it as such in an RFC

I don't have a strong opinion one way or another. I just felt it was
more coherent (with PDO) to use RuntimeException.

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

[PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

[BohwaZ]

Voting has now started for the RFC "Use exceptions by default in
SQLite3 extension":

https://wiki.php.net/rfc/sqlite3_exceptions

The vote is open for 2 weeks.

Thanks to the people who wrote the RFC howto page :)

BohwaZ

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

[PHP-DEV] [RFC] Last chance to discuss "Use exceptions by default in SQLite3 extension" before vote

[BohwaZ]

I'm planning to start the vote on this RFC in a week or two.

I changed the RFC to only have one proposal: deprecate warnings in PHP
8.3 and switch to exceptions in 9.0.

Feedback is welcome :) Thanks to people who have provided feedback
previously and on my PRs.

https://wiki.php.net/rfc/sqlite3_exceptions

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[BohwaZ]

Please no, I want to read e-mails when I want, with my own software,
leaving to me the freedom to mark things as important, or read, or
unread, or sort them in folders.

An important point : not all people in the world have access to the
internet at all time. Some people have to fetch the messages and read
them offline later. Also being able to be offline to write an e-mail is
much better.

Besides, there's already https://externals.io for people who prefer a
web interface.

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

Re: [PHP-DEV] [RFC] [Discussion] SQLite3: remove warnings, move to exceptions

[BohwaZ]

Hi,

I updated the RFC I added a second proposal where the only change would
be to throw exceptions by default in 8.3 instead of 9.0:

https://wiki.php.net/rfc/sqlite3_exceptions

I also changed the plan for 9.0:
"Calling SQLite3::enableExceptions(true) raises E_DEPRECATED, to alert
that the method will get removed"

As for people using enableExceptions(true) there was previously no
depreciation notice, and the method would just "disappear" without any
prior notice.

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

Re: [PHP-DEV] [RFC] [Discussion] SQLite3: remove warnings, move to exceptions

[BohwaZ]

> As others have said, the correct, responsible way to do this would be
> to make it gradual and keep warnings working until 9.0.  I would
> recommend:
> 
> 1. 8.3, enableExceptions(false) raises E_DEPRECATED.
> 2. 9.0 enableExceptions() defaults to true, and calling it with false
> is an Error.  (Calling it with true still works, but is a no-op.) 3.
> 10.0 Remove enableExceptions() entirely.
> 
> The behavior then only changes on major versions.

Thank you, I updated the RFC in that direction. The sad part is that it
will take a very long time before PHP 10.0 is released :(

> I think we already did this for PDO, didn't we?  It makes sense to do
> it for SQLite, too.

Slightly different:
https://wiki.php.net/rfc/pdo_default_errmode

PDO made the change to throwing exceptions without going through a
deprecation.

Maybe what I would prefer for SQLite3 is a middle-ground:
* we keep ''enableExceptions(false)'' with no plan to remove it ->
  thinking about it, it doesn't really matter if you prefer warnings,
  and it would be easy to keep it that way
* but we make SQLite3 throw exceptions by default directly in PHP 8.3,
  like it was done with PDO 2 years ago.

That way you can keep the same behaviour as before just by adding
enableExceptions(false) to your code, and it will not break.

That seems like a better compromise no?

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

[PHP-DEV] [RFC] [Discussion] SQLite3: remove warnings, move to exceptions

[BohwaZ]

Kia ora,

I am proposing that the SQLite3 extension stops using warnings for
errors and instead throws exceptions by default:

https://wiki.php.net/rfc/sqlite3_exceptions

Whether we just deprecate warnings first and default to exceptions, and
then remove warnings altogether in a later version, or just disable
warnings directly, is probably the important part of the RFC.

My personal point of view is that modern code probably already have
enabled exceptions in the class, or is transforming warnings into
exceptions using an error handler.

If not, it's relatively easy to set a exception handler to dismiss the
new exceptions if you don't want to see them.

So going throught depreciation might not be necessary, but it's open
for discussion.

Feedback is welcome :)

Thanks.

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

[PHP-DEV] SQLite3: implement session extension

[BohwaZ]

Hi folks!

2 years ago I implemented some missing APIs in the SQLite3 extension,
and I still want to get SQLite3 support in PHP to get better. Today
I'll be talking about something that can become very useful:

The SQLite3 session extension allows to create changesets from a
database, that is to store a set of changes that have been done, and
either revert them, or apply them to another database.

This is the same as using git or SVN but on a database file.

You can undo or replay a set of changes. This could also be used to
replicate changes to other servers.

You will find more details here:
https://www.sqlite.org/sessionintro.html

I am proposing to add (any help welcome, C is hard for me ;) )
two new classes to the SQLite3 extension if the session extension has
been compiled in SQLite:

* SQLite3Session
* SQLite3Changeset

This also means adding a new 'session' method to SQLite3.

An example of the projected use follows, as well as the proposed stub.

If SQLite has been compiled without support for this extension, then
both classes and the 'session' function won't be compiled either.

That way you will be able to check for feature support by using
class_exists('SQLite3Session'). (if that's not the best course, please
let me know)

As I said, I'm quite slow with C, and I have very little time, so I'm
asking here before proposing a RFC and finally if all goes well I will
be working on the complete implementation during 2023. Unfortunately I
cannot commit to targeting a specific PHP release as I don't know in
advance how much free time I may have.

Any constructive feedback is appreciated :)

== Example use: ==

$db = new SQLite3('db.sqlite');

$session = $db->session('test_table');
/* same as:
  $session = new SQLite3Session($db);
  $session->attach('test_table);
*/

$db->query('INSERT INTO test_table VALUES (42);');

$changeset = session->getChangeset();

file_put_contents('change.set', (string) $changeset);

unset($changeset, $session);

// ...

$changeset = SQLite3Changeset::load(file_get_contents('change.set'));
$operations = [
  SQLite3::INSERT => 'INSERT',
  SQLite3::UPDATE => 'UPDATE',
  SQLite3::DELETE => 'DELETE',
];

foreach ($changeset->iterate() as $change) {
  printf("%s on table '%s':\nOLD: %s\nNEW: %s\nPK: %s\n\n",
$operations[$change['operation']],
$change['table'],
json_encode($change['old'], JSON_PRETTY_PRINT),
json_encode($change['new'], JSON_PRETTY_PRINT),
json_encode($change['pk'], JSON_PRETTY_PRINT)
  );
}

$changeset->invert();

$changeset->apply($db);

== Stub: ==

 (string), // table name
'operation' => (int), // operation type
'old' => (array), // Old column values
'new' => (array), // New column values
'pk' => (array), // List of PK columns
*/
public function iterate(): iterator {}

/** @tentative-return-type */
public function apply(SQLite3 $db,
?callable $table_filter_callback = null,
?callable $conflict_callback = null): void {}

/** @tentative-return-type */
public function concat(SQLite3Changeset $changeset): void {}

/** @tentative-return-type */
public function invert(): void {}
}

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

Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte

[BohwaZ]

2MB is probably too low and it can be set at something like 20MB,
but from my understanding setting it low enough will help prevent DoS
attacks.

If we change it to something larger, I'm not sure exactly what would be
the effect of changing this default for mass-hosting providers where
they can have thousands of Wordpress/Drupal/etc. setups on a single
node. Changing from 2MB to 20MB for all requests may have quite an
effect if there is an attack. Surely all those providers have teams
dedicated to setting the right limit, but that shouldn't stop us from
using a safe default.

What is unpractical with upload_max_filesize and post_max_size though is
that we can't set the limit for each script, because it affects how PHP
is parsing the POST body before the script is even parsed.

Unless at one point we provide some kind of option to set ini literals
from within a script file before the request is processed (eg.
declare(post_max_size=256M) or something like that), the only option is
to use the web server to change the setting.

That way most endpoints will benefit from a low limit, and only
the targeted scripts or directories will have a higher limit.

For example with Apache something like that will only change the
limit for the parts of the admin where it's needed, and when the HTTP
client has a cookie:


php_value post_max_size 256M
php_value upload_max_filesize 256M


I commented with this snippet on relevant documentation pages,
hopefully it will help people looking for that kind of info to do
something a bit better than to set this limit for the whole server.

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

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[BohwaZ]

> > The 4th one is very useful.
> >
> > $v = ${'param_' . $name};  
> 
> Like Rowan mentioned, the RFC does not propose to deprecate variable
> variables, just variable variables as a form of string interpolation.
> You'll still be able to use variable variables, even in strings, like
> noted above, just as form 2.

Thanks for clarifying :)

Sounds good for me then :)

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

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[BohwaZ]

> The RFC is *only* about how variables are interpolated *inside quoted
> strings*.

Then it doesn't seem clear in the RFC that it's limited to variables
inside strings, maybe it should be made clearer that it's only proposed
to deprecate that syntax inside strings, and not the variables
variables feature :)

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

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[BohwaZ]

This RFC is confusing two different things:

1. variables inside strings (options 1, 2, 3)
2. dynamic variables names (option 4)

The 4th one is very useful.

$v = ${'param_' . $name};

There is no other practical way to do that, so removing that feature
would mean breaking something useful with no replacement.

Also why break something that works and is used?

If it feels too confusing, you could just deprecate use of the "${...}"
syntax inside strings, but still I don't feel like it's very confusing
and would bring more hassle that it's worth (a bit like the 8.1
depreciation of null for string functions, it's such a pain to deal
with).

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

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[BohwaZ]

Same thing, not everyone wants to use strict types, and the change in
PHP 8.1 is a pain, adding (string) everywhere just means adding more
code with no gain just to get around a limitation of the language.

So thank you Craig for this RFC :)

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

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

[BohwaZ]

We should do the same with SQLite3 extension.

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

Re: [PHP-DEV] SQLite3, PDO/SQLite and driver specific methods

[BohwaZ]

On Tue, 16 Jun 2020 11:32:01 +0100 / Peter Bowyer
 said :

> Hi list,
> 
> 4 months ago there was a discussion about the future of SQLite3 and
> PDO/SQLite extensions (https://externals.io/message/108256),
> highlighting the effort required to maintain two codebases.

Yes and I haven't had time to write a RFC or write any code on that
yet, but hopefully I will have some time next year...

> PDO is well established as providing a standardised access layer
> across databases. SQLite requires extensions to be loaded to gain
> feature parity with other databases (e.g. to load geospatial
> functions) and since it is not a database server these have to be
> loaded at runtime. PDO has three sqlite-prefixed functions
> (https://www.php.net/manual/en/ref.pdo-sqlite.php) but not one to
> load extensions.
> 
> Is it a problem to add one?

Yes adding driver-specific methods to PDO has been refused by PHP
developers when I did a RFC on adding a couple methods for SQLite, even
though there's already a bunch of other methods for other drivers like
Postgre.

What I was thinking was not exactly what Dan was proposing as I
remember the driver-specific code to be very much linked to the PDO
class and changing that would be a lot of work, so I was more thinking
about adding a "getDriver()" method on PDO that would return a
"PDO_SQLite" instance (or other drivers) and this class would have
driver-specific methods.

I dont exactly remember why the inheritance path suggested by Dan seemed
way too complex as I haven't had time to work on this for a long time,
but if it is actually possible it also seems like a good way to go :)

I personally already use a wrapper-class that implements the same PDO
methods but using the SQLite3 class underneath as it's the only one to
provide access to advanced features like setting the authorizer
callback, backup API and others.

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

[PHP-DEV] The future of SQLite3 and PDO/SQLite extensions

[BohwaZ]

Kia ora,

As some of you may or may not know, I've been working on improving the
state of SQLite support in PHP on my free time in the last few years:
https://github.com/php/php-src/pulls?utf8=%E2%9C%93=author%3Abohwaz

The last one was adding a userland authorizer callback, which should be
quite useful to reduce security issues with SQL statements :)

I've done a past RFC on getting some of SQLite features in PDO but it
didn't get a great success:
https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo

I'm coming back on that point: the relationship between SQLite and
PDO_SQLite, as I think it is important for moving forward.

What is not shown in my pull request history is that I also worked on
some other issues on which I gave up as my time and energy ran out and
I've come a number of times on issues that were only affecting one or
the other extension.

The current state of things is that the PDO_SQLite and SQLite3
extensions do differ on some points but are also very similar on
others. But the fact is that the code is completely different and for
every issue fixed in one, we also need to fix it in the other, or they
might have different issues. This is due to the fact that there are in
fact two implementations of the SQLite API in PHP. So twice the effort.

I don't think that's the best way forward.

I think that PDO_SQLite should get the same features as the SQLite3
extension, and the SQLite3 extension should be deprecated and
eventually removed and replaced by a userland library that would wrap
around the PDO_SQLite API. This means that the BC breaking should be
reduced to just installing a new composer package.

Ditching the SQLite3 extension would reduce the development efforts and
possible bugs I think. It would also make it easier for newcomers as
only one API will be available, without having to choose between the
two without knowing that some features will be available in one but not
the other.

Does that seem like a good idea to anyone else?

And if that's the way forward, how should I proceed to port SQLite3
features to PDO_SQLite and get that accepted?

Cheers,

BohwaZ

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

[PHP-DEV] Help with memory leak on zend_call_function

[BohwaZ/PHP]

Hi all,

I am working on this PR: https://github.com/php/php-src/pull/4797

It implements the ability to set a userland callback function that would 
allow or deny SQL queries in SQLite using its internal authorizer logic. 
This is a native feature of SQLite that is currently missing from the 
PHP extension.


It's quite straightforward, but I could not find much documentation on 
zend_call_function and fci/fcc.


So I just tried to find existing examples that did the same (calling a 
userland function callback from the C extension) and mostly used the one 
from libxml.


So it works well, but I'm stuck on a memory leak, even though I'm using 
zend_fcall_info_args_clear.


I'm not sure what's going on here and why.

So if someone could take a look or point me in the right direction, that 
would be great :)


Thanks!

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

Re: [PHP-DEV] The real world ...

[BohwaZ/PHP]

Le 13/06/2019 14:20, Lester Caine a écrit :

On 13/06/2019 13:04, Andrey Andreev wrote:

You have logs to see the errors; relying on your users to report the
actual error messages to you is the worst way to do it.


How many website logs can you manage on a daily basis? Given the
volume of material in heavily used website. I am STILL trying to get
long established sites back to a state where that would be a practical
approach. Especially when adding material is first element on the
to-do list. I've several hours of such work to get cleared first and
prompts in that traffic is easier to manage than then working through
several machines worth of logs ...


Have you considered using solutions like Sentry? 
https://sentry.io/welcome/


It gets added to the error handler and will report errors to a server. 
Quite handy.


Another solution is to use the shutdown and error handler to send an 
email to you when there is an error:


https://stackoverflow.com/questions/277224/how-do-i-catch-a-php-fatal-error

We used that solution for quite some time, but it can quickly overload 
your email server when you have millions of requests producing errors ;)


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

Re: [PHP-DEV] The real world ...

[BohwaZ/PHP]

If you're so keen on providing the user something to see without having
to use display_errors=on: Have you had a look at
https://php.net/register_shutdown_function ?

You can always use that to figure out whether there was a fatal error
and then display something nice to the user.

No leaked stacktrace, no leaked credentials, user is informed, everyone
is happy :-)


Yup everyone should do that.

I personally like Tracy from Nette which has a production mode that will 
show a nice error page: https://tracy.nette.org/en/guide


Perhaps PHP should display a page like that instead of a blank page when 
display_errors is on "Off" no?


I've seen newcomers to PHP getting quite disturbed by just getting a 
blank page and nothing else.


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

Re: [PHP-DEV] open_basedir?

[BohwaZ]

On Fri, 10 May 2019 22:55:51 +0200 / Niklas Keller 
said :

> That's exactly the reason why I'm for removing it. There will always
> be ways to circumvent open_basedir and setups like this are insecure.
> It gives a false sense of security. It's not better than nothing,
> because most hosting providers would opt for a real solution instead
> of leaving users entirely unprotected.

What's your solution then? I'll be more than happy to have anything
better that will work with thousands of users :)

Also I don't get the argument that because it isn't perfect it would
not be useful. It definitely is, as a security measure.

chroot isn't perfect either, but you might want to use it as well.

Same for disable_functions, sure there will be ways to go around it,
but it will still block 90% of attacks we might get. So, definitely not
the most reliable thing, but it adds a layer that may help.

I can pick the lock on my front door in about 10 minutes, a
professional probably much less. And you can enter by breaking a window.
But it is still effective as a security measure. And it would be silly
if someone would come and tell me that the lock should be removed
because it gives a false sense of security :)

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

Re: [PHP-DEV] open_basedir?

[BohwaZ/PHP]

Kia ora,

I'm against deprecating it or removing it.

As said earlier, it has some security value, especially with mass 
hosting. If I'm hosting thousands of websites for thousands of users, 
using chroot is not doable, and open_basedir is a good alternative (at 
least it's better than nothing).


That's why it's used by ISPconfig and other panels: there is no other 
solution that I know of.


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

Re: [PHP-DEV] Mitigate “Magellan vulnerabilitites” in PHP 7.2?

[BohwaZ/PHP]

Thanks Christoph!

Just to be clear, this patch doesn't prevent security issues if you 
don't update your SQLite3 library, it just implements a new option 
available in newer SQLite versions which will prevent arbitrary changes 
to the internals of a SQLite database only if you SQLite3 library is 
3.26+. Changing the internals of a SQLite database is something that 
should be quite rare in the real world I think.


This addresses potential security issues for PHP applications allowing 
end-users to run arbitrary SQL queries.


But please note that if your application does allow end-users to run 
arbitrary SQL queries, I advise that you limit them to read-only by 
either:


* opening the database as readonly (available in PDO since PHP 7.3: use 
open attribute: PDO::SQLITE_ATTR_OPEN_FLAGS => PDO::SQLITE_READONLY)
* using the SQLite3Stmt::readOnly method (will tell you if a prepared 
statement will write to the database)

* or using the equivalent for PDO:

$st = $pdo->prepare('SELECT * FROM table;');
var_dump($st->getAttribute(PDO::SQLITE_ATTR_READONLY_STATEMENT));

This last one should be available in PHP 7.4 I hope? See 
https://github.com/php/php-src/pull/2760


Both PDO features are currently undocumented but it's on my TODO list as 
well.


If your users are performing custom SELECT queries, this is the best 
thing to do.


I am now working on bringing support for a userland custom callback to 
the SQLite3 authorizer API, this will allow PHP code to restrict access 
to specific tables, columns and operations, that should also improve 
security in the future.


As a side note, although my time is quite limited, I have worked for the 
last two years to improve features support and security of the SQLite3 
extension and try to match features of the SQLite3 extension in PDO as 
well.


I have to give a warm thank you to Christoph and everyone else who 
helped me in this :)
And if anyone is interested in helping me improve SQLite support in PHP 
you are more than welcome :)


Cheers.

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

Re: [PHP-DEV] New website for the PHP project

[BohwaZ/PHP]

Could not find anything about PDOStmt::setParam either, but I fixed it
for you: http://php.net/pdostatement_bindparam
You're welcome ;)


Ah ah good catch :) I meant bindParam obviously ^^

The fact is http://php.net/bindparam
will return nothing about PDOStatement::bindParam

which is kind of weird :)

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

Re: [PHP-DEV] New website for the PHP project

[BohwaZ/PHP]

Le 04/02/2019 01:14, azjezz a écrit :

In my opinion, current design looks old, outdated and bland. This
sadly may reflect "badly" on the language reputation nowadays.


I find that the main PHP website is quite good actually, the design 
looks modern, it is quite clear and easy to use and it provides great 
access to documentation.


I have to say the PHP documentation is usually great (and when it's not, 
just change it :) ), and the feature where you can just type 
php.net/function to get direct access  to the documentation of a 
function/feature is great, although it doesn't search in methods, eg. 
http://php.net/setParam will not return anything about PDOStmt::setParam 
:(


I also love the comments feature, people often provide great examples, 
tips or replacement functions for old PHP versions, this is very 
helpful!


So I don't think that we need to redesign and start over, but iterate 
and make the current website better, please don't throw out what is 
already good :) It would be a recipe for disaster.


But I have to agree that signing to the internals list wasn't an easy 
task as the website form wasn't working when I subscribed 2 years ago, 
but it might have been fixed?



# FrontEnd Framework

We don't need that too, but we can use one ! there's some light-weight
options out there.


Please only use HTML and CSS, don't use a JS framework. The website 
should be future-proof and not broken and hard to maintain in 6 months. 
Also it should be lightweight and not download a bunch of code just to 
display stuff. HTML and CSS are more than plenty for our needs :)



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

Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting

[BohwaZ]

AFAIK, gettext functions do depend on setlocale.

I wish so much that it wasn't the case (as you then need to have the
locale installed on the system), but it is, so setlocale definetely is
quite used in the wild and deprecating it seems a bit far-fetched
unless we can actually replace it with something else (better).

But gettext has other issues related to being cached in the current
process, as you need to restart apache if the compiled .mo files have
changed to get the new strings :(

Another function that is influenced by setlocale is strftime. This is
often the common way to display a date in a different language.

So I'm all for deprecating setlocale but before that we would need to
have something better for everything that's currently depending on it :)

BohwaZ

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

Re: [PHP-DEV] Unbundle libsqlite3?

[BohwaZ]

On Wed, 19 Sep 2018 19:41:11 +0200 / "Christoph M. Becker"
 said :

> PR #2698[2] seems to require an RFC.  IMHO, it's best to present RFCs
> and voting on them as early as possible (instead of rushing them at
> the last moment). :)

Yeah there was an RFC and it was voted no:
https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo

Discussion was that current PDO way of handling DB-specific features is
not the best. Unfortunately no one volunteered to change that fact, and
as my patch wasn't approved PDO_SQLite is still behind SQLite3 and
missing features.

I was actually talking about https://github.com/php/php-src/pull/2760
which was approved just after feature freeze of PHP 7.3.

> I agree that an exception would be better.  A sensible alternative
> might be to not even include the method for older libsqlite3.  Either
> way, a PR targeting master would be welcome.

Yeah unfortunately due to the result of the previous RFC I stopped my
efforts trying to bring up pdo_sqlite and SQLite3 up to date. I have
very little free time, so spending it for useless patches is not the
best use of it, sorry.

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

Re: [PHP-DEV] Unbundle libsqlite3?

[BohwaZ]

On Mon, 17 Sep 2018 15:16:13 +0200 / "Christoph M. Becker"
 said :

> Hi!
> 
> We bundle an unmodified libsqlite3 for at least two years.  Since then
> all updates go into any dev, alpha and beta releases, while security
> patches (usually backports from libsqlite3) go into stable branches.
> 
> ext/sqlite3 requires libsqlite ≥ 3.3.9[1] which has been released on
> 2007-01-04[2] (i.e. more than eleven years ago!).  ext/pdo_sqlite has
> no specific version requirement; there is a check for
> sqlite3_open()[3] which I believe is available since 3.0.0.

I believe that SQLite3Stmt::readOnly requires SQLite 3.7.4 released in
2010, bundled since PHP 5.3.6 (!).

There is also a PR patch (from me) that should make it in PHP 7.4 that
implements this feature in pdo_sqlite too.

I believe this is the most recent feature that we are using. But it
should return false if the SQLite version installed is older than that
(IMHO it should throw an exception instead, but that's the current
behaviour anyway).

As for bundling or not, I'm on Devuan and it is using the system
version of SQLite as far as I know so I don't see the need to bundle it
with PHP, but I don't have a good view of whether it might be needed on
other platforms.

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

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

[BohwaZ]

On Mon, 30 Oct 2017 20:11:18 + / Rowan Collins
 said :

> On 30/10/2017 03:14, Dan Ackroyd wrote:
> > The vote for this should have ended..3 days ago.
> >
> > At which point I believe the vote was actually passing.
> 
> 
> Hm, that's awkward!
> 
> For the record:
> 
> - voting was announced on the evening of the 9th "for two weeks"
> which would imply the evening of the 23rd
> - however, the e-mail also said "Vote will end on Wednesday the 25th
> of October. "

Don't know where that 9th is from? I posted my email around 11 am on
Tusday October 10th, so +2 weeks is Tuesday October 24th, but I thought
it would close at midnight, so on the 25th :)

> - the wiki page states "Vote closing on Oct 27, 2017."

My bad there, sorry, I counted two weeks from when someone told me to
put the date on the wiki (which I forgot to do).

> - https://php-rfc-watch.beberlei.de/ lists "daverandom" voting No at 
> 2017-10-28T07:28:00+ (*mutters something about relative date
> display being uselessly vague*)
> 
> 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.

Ah yeah didn't thought of that, but I'm in NZ, so the dates I
talked about were UTC+13.

> In my opinion, the very fact that it was this close suggests that
> there is not consensus in favour of the change, and therefore it
> would be reasonable to err on the side of caution, and not adopt the
> change.

Agreed.

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

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

[BohwaZ]

On Wed, 01 Nov 2017 19:08:56 + / Rowan Collins
<rowan.coll...@gmail.com> said :

> On 1 November 2017 17:47:55 GMT+00:00, BohwaZ <p...@bohwaz.net> wrote:
> >I can't find the place where we can see the voting history? Last
> >time I checked the page last week it was 6 to 5 or something like
> >that.
> 
> See my email in this thread from a couple of days ago. Last vote was
> a yes, but probably too late, leaving 6:6, which means no consensus
> to merge this implementation.
> 
> Hopefully we can get some momentum behind a more general API that
> allows this feature in a way that will be more positively received.

OK, thanks. I marked the RFC as rejected.

I'll be leaving this list now as this marks the end of my
contributions to PHP, as my free time is very limited and I want to
spend it on useful activities.

So good luck to the next person who will rewrite that part of PDO, if
that happens.

Thanks everyone :)

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

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

[BohwaZ]

Sorry I thought the vote would automatically close, but apparently it
doesn't work like that. I was away from the internet so couldn't edit
the wiki page.

I can't find the place where we can see the voting history? Last time I
checked the page last week it was 6 to 5 or something like that.

On Mon, 30 Oct 2017 03:14:03 + / Dan Ackroyd
<dan...@basereality.com> said :

> The vote for this should have ended..3 days ago.
> 
> At which point I believe the vote was actually passing.
> 
> cheers
> Dan
> 
> On 9 October 2017 at 23:12, BohwaZ/PHP <p...@bohwaz.net> wrote:
> > Kia ora,
> >
> > After some more discussions, I don't think we have much left to
> > discuss on that topic, so…
> >
> > Voting is now open for 2 weeks on this RFC:
> > https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo
> >
> > Vote will end on Wednesday the 25th of October.
> >
> > Thanks to everyone who contributed to the discussion so far :)
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 

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

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

[BohwaZ/PHP]

Le 12/10/2017 12:00, Dan Ackroyd a écrit :

On 11 October 2017 at 22:03, BohwaZ/PHP <p...@bohwaz.net> wrote:

Hey,

For people voting against the RFC, could you please explain your vote 
here

so that we might understand?

Cheers.


I think people were reasonably clear during the discussion.

Having certain methods only available on an object depending on how it
was initialized is just not a good idea.


As far as I know, no one volunteered to rewrite PDO to change that?

I don't really understand that logic. Yeah the existing behaviour is not 
optimal. But there is no other solution right now.


Should we also stop adding any feature to PHP because most PHP functions 
are named incoherently and we need to wait until all of them are renamed 
correctly? Hopefully not :)


It might be years (or never) before that PDO behaviour is changed. In 
the meantime PHP will just be missing features that could have been 
provided, this sounds strange to me.


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

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

[BohwaZ/PHP]

Hey,

For people voting against the RFC, could you please explain your vote 
here so that we might understand?


Cheers.



Kia ora,

After some more discussions, I don't think we have much left to
discuss on that topic, so…

Voting is now open for 2 weeks on this RFC:
https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo

Vote will end on Wednesday the 25th of October.

Thanks to everyone who contributed to the discussion so far :)



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

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

[BohwaZ/PHP]

Kia ora,

After some more discussions, I don't think we have much left to discuss 
on that topic, so…


Voting is now open for 2 weeks on this RFC:
https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo

Vote will end on Wednesday the 25th of October.

Thanks to everyone who contributed to the discussion so far :)

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

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

[BohwaZ/PHP]

I believe that's how PDO::PARAM_LOB is intended to work (based on my
reading of the docs and implementations for other drivers). It seems 
like
more of a convenience than anything, though maybe someone had more 
ideas
for how it should work across drivers and never got to follow through 
on it.


This is not how I understand the documentation:

"PDO::PARAM_LOB tells PDO to map the data as a stream, so that you can 
manipulate it using the PHP Streams API."


But this seems to be quite chaotic, reading 
https://secure.php.net/manual/en/pdostatement.bindcolumn.php


"Since information about the columns is not always available to PDO 
until the statement is executed, portable applications should call this 
function after PDOStatement::execute().


However, to be able to bind a LOB column as a stream when using the 
PgSQL driver, applications should call this method before calling 
PDOStatement::execute(), otherwise the large object OID will be returned 
as an integer."


This is quite confusing.

And as stated above, with MySQL and SQLite it returns the LOB content as 
a string on PHP 7+ but a stream handle on PHP 5.6…


To me it seems that the LOB handling of PDO via bindColumn/bindParam is 
completely broken and inconsistent currently :(


If I have more time available after this RFC I'll look into fixing it 
for PHP 7.3.



I'd love it if PDO had better BLOB/LOB types and if we had a better
pattern for driver-specific APIs, but I'm comfortable lumping those 
goals
under "future scope." Getting parity with ext/sqlite3 will make 
pdo_sqlite
more usable, which will help grow its community, and the number of 
people

who are able to contribute to these bigger projects. Deprecating the
current set of driver-specific APIs in the future, if we have 
functional

equivalents, isn't an impossible project.


Yeah sounds good to me :)

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

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

[BohwaZ/PHP]

Taking it to a better solution is that the method sqliteCreateFunction
shouldn't exist on the PDO class, but instead on a PDOSqlite that
extends PDO.

class PDOSqlite extends PDO {
 public function createFunction(...) {...}
}

class PDO {
public static function connect(string $dsn [, string $username [,
string $password [, array $options ]]]) {
   // if connecting to SQLite DB {
   return new PDOSqlite(...);
   }
}
}

This might be a mistake in how it was implemented originally. Looking
back it seems that it was implemented before we had the RFC
processand is exactly the type of 'sub-optimal' implementation the
RFC process is meant to prevent.


Yes I do agree that the method overloading of PDO by drivers is not the 
best to say the least.


If you feel like rewriting a large part of PDO feel free :) but I don't 
have time for that, and it's not the subject of this RFC :)



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

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

[BohwaZ/PHP]

On 02/10/17 01:48, BohwaZ/PHP wrote:

So for me the use case is quite different here, and openBlob allows
stuff that PDO::PARAM_LOB with bindColumn and bindParam cannot allow
currently. In conclusion openBlob is still useful as it allows 
accessing

a BLOB outside of a statement and allows to read and write at the same
time without having to load the blob in memory.


This is where the limitations of some of the other database engines 
come

into play. In many cases in shared hosting, the database is provided on
another machine, so one has to transfer the data results between
machines and do not have direct access to the data. PDO can't emulate
this function so the question is still SHOULD something that can't be
made generically functional be allowed in PDO. Personally I would 
prefer

that for this sort of action the generic driver was used used rather
than PDO and I have to do that for other functions in other databases
currently anyway. So one does not have to overload PDO with more checks
as to if your code will work on the different drivers.


I don't agree with that.

You might want to be able to use a generic abstraction layer such as PDO 
to offer support for multiple database engines without having to create 
your own abstraction layer with every specific database extension (that 
would be huge work) but still be able to access driver-specific features 
if available.


This is why I am pushing for PDO to be feature-full, so that you have 
the choice to use PDO and not have to implement your own abstraction 
layer just because you need one specific feature in one single case :)


If you follow your logic, then PDO::sqliteCreateFunction shouldn't 
exist, and this would make the PDO sqlite driver pretty much useless as 
SQLite is missing a number of important functions.


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

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

[BohwaZ/PHP]

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 interesting indeed, didn't know about that feature, I was
expecting the creation of a new method was the only way, as this was
the way PGSQL was doing it.

There's even a bug report about it:
https://bugs.php.net/bug.php?id=57691

I will look into that next week and see if it can fit and replace my 
RFC

then.



OK, I took some time to look into that feature and the fact is that it 
doesn't work at all currently with SQLite, it is not returning a 
resource handle but a string, and it is consuming a large amount of 
memory as it is just dumping the LOB in memory. The code seems to be 
there to handle it though so I don't know what's going on, if the person 
who implemented that could come forward and tell me more about the 
implementation.


But I tried it and it doesn't cover one of the use of openBlob that I 
have which is to open, read, and write at the same time.


The current way it's done in PDO is that you can either fetch a LOB from 
a result of a query and read from it, or bind a file resource handler to 
a statement for writing, but you cannot open a LOB, read from it and 
write from it without performing a query.


So for me the use case is quite different here, and openBlob allows 
stuff that PDO::PARAM_LOB with bindColumn and bindParam cannot allow 
currently. In conclusion openBlob is still useful as it allows accessing 
a BLOB outside of a statement and allows to read and write at the same 
time without having to load the blob in memory.


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

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

[BohwaZ]

On Wed, 27 Sep 2017 11:47:21 +0200 / Matteo Beccati 
said :

> On 27/09/2017 11:34, Lester Caine wrote:
> > openBlob is a specific feature of SQLite so the decision to use it
> > already rules out any other database. IN PDO access to it via the
> > generic blob functions is the proper way forward so that a call for
> > a blob gives a blob what ever the underlying datbase.
> 
> Seeing the RFC, I gave for granted that SQLite couldn't use the
> standard LOB api provided by PDO, but maybe that isn't the case? I'll
> leave the OP to reply.

I wasn't aware of that API, I saw what the postgreSQL driver was doing
and assumed it was the only way.

See my response to @cmb but it seems like a nice option, I'll assess
next week whether it can fit with the SQLite C API or not. Hopefully
it will!

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

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

[BohwaZ]

On Wed, 27 Sep 2017 11:41:50 +0200 / "Christoph M. Becker"
<cmbecke...@gmx.de> said :

> On 26.09.2017 at 04:03, BohwaZ/PHP wrote:
> 
> > 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.
> > 
> > https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo
> > 
> > Discussion should happen in the next two weeks before going to vote.
> > 
> > The actual patch is here: https://github.com/php/php-src/pull/2698
> > 
> > Suggestions and discussions welcome.
> 
> 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] <http://www.php.net/manual/en/pdo.lobs.php>
> 

Very interesting indeed, didn't know about that feature, I was
expecting the creation of a new method was the only way, as this was
the way PGSQL was doing it.

There's even a bug report about it:
https://bugs.php.net/bug.php?id=57691

I will look into that next week and see if it can fit and replace my RFC
then.

Thank you.

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

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

[BohwaZ]

On Wed, 27 Sep 2017 09:47:51 +0100 / Dan Ackroyd
<dan...@basereality.com> said :

> On 26 September 2017 at 03:03, BohwaZ/PHP <p...@bohwaz.net> wrote:
> > Kia ora,
> >
> > https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo
> 
> 
> Couple of questions:
> 
> > $stream = $pdo->sqliteOpenBlob('test', 'data', 1);
> 
> I tried reading the code but failed; what happens when this is called
> on a PDO connection that isn't to an SQLite database? Also, there
> should probably be tests around that behaviour.

As with other driver-specific methods of PDO, the method won't be
defined and an exception (error) will be raised.

I'll add that detail ASAP thanks.

This is an existing issue when you want to extend PDO to implement lazy
connections (eg. you can't call PDOExtended::sqliteCreateFunction until
the parent constructor of PDO has been called), but is out of the scope
of this RFC.

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

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

[BohwaZ/PHP]

Kia ora,

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.


https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo

Discussion should happen in the next two weeks before going to vote.

The actual patch is here: https://github.com/php/php-src/pull/2698

Suggestions and discussions welcome.

Cheers.

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

Re: [PHP-DEV] Request access to wiki for RFC on implementing missing pdo_sqlite features

[BohwaZ/PHP]

Hello, anyone? :)


Kia ora,

I'm requesting access to wiki to be able to write the RFC on
implementing missing pdo_sqlite features, following pull request
https://github.com/php/php-src/pull/2698 and discussion on this list.

My account on the wiki is "bohwaz".

Cheers.



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

[PHP-DEV] Request access to wiki for RFC on implementing missing pdo_sqlite features

[BohwaZ/PHP]

Kia ora,

I'm requesting access to wiki to be able to write the RFC on 
implementing missing pdo_sqlite features, following pull request 
https://github.com/php/php-src/pull/2698 and discussion on this list.


My account on the wiki is "bohwaz".

Cheers.

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

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

[BohwaZ]

On Thu, 24 Aug 2017 11:55:10 +0200 / "Christoph M. Becker"
<cmbecke...@gmx.de> said :

> It seems to me this is rather simple: if a feature is uncontroversial,
> it doesn't need an RFC.  Since nobody objected against PR #2528, it
> was merged (after some weeks).  However, there have been objections
> against PR #2698, so an RFC appears to be appropriate.

Cool, that's a rule that makes sense :) maybe it should be in the
contributing guide?

Can someone give me RFC power on the wiki (my account is "bohwaz")?
Thanks.

Should I include the proposal for adding the PDOStatement::readOnly()
method?

Should it be named PDOStatement::sqliteReadOnly() or readOnly()? I have
no idea. Or should it even be PDO::sqliteIsReadOnly($statement)?

I think that adding read-only and read-write opening options for SQLite
PDO shouldn't raise any eyebrows here as it doesn't involve any new
method, so I'll do a separate patch for that. Anyone objecting?

Cheers.

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

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

[BohwaZ/PHP]

Le 23/08/2017 16:57, Marco Pivetta a écrit :

I suggest adding dedicated functions that given a PDO instance and the
parameters you needed do what you want to do.


So if I understand correctly:

$pdo = new PDO('sqlite::memory:');
$extended = new PDO_Extended_SQLite($pdo);
$blob = $extended->openBlob(...);

That's kinda better, but that doesn't solve much, as that means that 
only one method will be in this new class, and PDO will still have 
sqliteCreate... methods

 as we won't cause unnecessary BC breaks.

I'm not a C developer though and I don't see how that would be possible.

My feeling is that it would have been better to have a class extending 
PDO for each driver, adding additional constants and methods, but that's 
not how PDO has been designed, and I'm not gonna suggest that we should 
rewrite PDO now.



And yes, you are adding new stuff: php-src has this widespread
misunderstanding that "reproducing new lower layer behaviour in upper
layers" should happen no matter what.


I don't get your point, this is already in a upper layer no? PDO already 
has that for SQLite and I just checked and pgSQL too:


PDO::pgsqlCopyFromArray
PDO::pgsqlCopyFromFile
PDO::pgsqlCopyToArray
PDO::pgsqlCopyToFile
PDO::pgsqlGetNotify
PDO::pgsqlGetPid
PDO::pgsqlLOBCreate
PDO::pgsqlLOBOpen
PDO::pgsqlLOBUnlink

I'm not gonna create another way of having driver-specific features that 
wouldn't make sense in relation to existing methods, and I don't have 
time to rewrite a significant part of PDO that would cause a major 
BC-break.


We all agree that this is not the best way, but it's too late for that I 
think.


So can we go back to topic?

I'm just trying to improve existing PHP in the (very little amount of) 
free time that I've got, following what has already been done, not 
trying to refactor/reinvent/do major changes stuff here.


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

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

[BohwaZ/PHP]

PDO is already a mess, and adding method that appear/disappear 
dynamically

whether you enable an extension or not... is a horror show.

From my PoV, since we (doctrine) have to abstract away from it all the
time, we'd rather have it as tidy and well-thought-out as possible,
especially since there already is so much damage done.


Yes I agree, but it's not the point, this behaviour already exists, I'm 
not introducing anything new here.


Couldn't care less about exposed/unexposed features if the endpoints 
are on

the wrong object, or cause even more weirdness to work with. It is not
helpful: it's just more tech debt dumped on millions of consumers.


I care because I need those features in my projects, and I'm not the 
only one.


But if those late-loading methods don't suit you, what do you propose 
instead?


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

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

[BohwaZ/PHP]

Yes, because once it lands in core, it sticks around for almost 
eternity.


Yeah but is it necessary for something that is just missing, because the 
pdo_sqlite implementation is incomplete, and is basically following what 
already exists, without changing anything?


That change was implemented in the SQLite3 extension without a RFC, so 
I'm quite confused here.


I kinda feel like it's a weird thing to submit an RFC that would 
basically ask the question "should pdo_sqlite only implement a subset of 
SQLite", because well it is most likely that if you are using a DB 
driver with PDO you most likely want to be able to access that DB 
features, no?


Or are you saying that we should have a vote on whether the 
implementation should follow what is already existing in PDO or should 
propose something new instead? Because I frankly don't know what would 
be a better idea than driver-specific methods and I don't know enough 
C/have enough time to do anything else, so I won't submit any 
proposition that I won't be able to do myself.


Cheers.

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

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

[BohwaZ/PHP]

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
driver-agnostic API, but that's not to say we couldn't hash something 
out.


Do we need a RFC every time we patch for a missing method ?

Btw there's already sqliteCreateFunction, sqliteCreateAggregate and so 
on, so it's pretty much just the continuation of that logic, even though 
I don't really like it either (especially as lazy-loading by extending 
PDO makes it so that the methods are not accessible until the connection 
has been established, which is a weird behaviour imho).


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

[PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

[BohwaZ/PHP]

Hi people of the PHP world,

I just have proposed a patch to have SQLite3 open_blob feature 
implemented in PDO_SQLite: https://github.com/php/php-src/pull/2698


This follows my patch to implement this feature in the SQLite3 extension 
a few months ago.


Now my aim is to implement missing features in pdo_sqlite that are 
already present in the SQLite3 extension (target is PHP 7.3 I guess). 
I'm also keen to implement any SQLite3 feature offered by the C library 
that are not already present in either extensions (if any).


This way we will be able to use either PDO or SQLite3 extension, and 
have access to the same features.


Here are the features that are currently present in the SQLite3 
extension but missing in PDO:


- bool Statement::readOnly() -> returns true if the statement doesn't 
write to the database
- Opening a database as read-only (using SQLite flags OPEN_READWRITE, 
OPEN_READONLY and OPEN_CREATE)


Please tell me if you see anything else that I missed and I'll add it to 
my todo-list.


Thanks.


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

Re: [PHP-DEV] OBJECT_OPERATOR vs. DOUBLE_COLON

[BohwaZ/PHP]

Le 06/07/2017 16:46, Stanislav Malyshev a écrit :

Hi!


I think that using :: on a variable that contains an object should not
"fall back" to a static access on the object's class. Instead the
runtime should error out.


Why should it not do what it does now? What would it achieve? I don't
see any improvement in changing that - it may break code that is using
this facility, and it won't make anything better. True, this is an
exotic and non-obvious feature, but many languages have such features,
which are used only by people that need them. If we proposed to add 
such

feature, true, it may be too exotic to be added on its own merits, but
since it is already there (and, probably, used in some code somewhere) 
-

why bother messing with it? I don't see how just leaving it be hurts
anything.


True.

I'm using that feature all the time to access static variables and 
constants, it's just more convenient to use the variable referencing the 
object than having to remember and type the name of the class (plus it's 
more obvious when reading the code back).


Though I very rarely use it for accessing static methods, I don't see 
why this should throw an error, this feature makes sense as '::' is 
always for accessing static stuff, it is quite logic in the end:


:: for static (constants, static variables, static methods)
-> for the rest

I think this feature is documented somewhere in the doc, that's where I 
learnt it from if I remember correctly.


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