My previous email had an ambiguous subject line. My apologies.
I've moved my RFC to the voting phase.
The proposal:
> Add a function that exposes the warning count of the most recent
statement for MySQL: $pdo->mysqlGetWarningCount(). It returns an int
straight from the MySQL driver. This fixes th
I've moved my RFC to the voting phase.
Voting will be open till 2020-07-21
https://wiki.php.net/rfc/pdo-mysql-get-warning-count
The pull request (with tests) is here:
https://github.com/php/php-src/pull/6677
Thanks for your time!
Daniel
fixes the open bug: https://bugs.php.net/bug.php?id=51499. If there is no
other feedback in a day or two, I'll probably move it to "In Voting".
https://wiki.php.net/rfc/pdo-mysql-get-warning-count
Thanks in advance for your thoughts!
Daniel Beardsley
On Fri, Feb 26, 2021 at 8:45 A
Hi,
I've gotten very little feedback on the "should I make an RFC about this?"
question, so I went ahead and made an RFC:
https://wiki.php.net/rfc/pdo-mysql-get-warning-count
This is about a feature in an open pull request:
https://github.com/php/php-src/pull/6677
which addresses an open issue in
. The first step is emailing!
I'd like to propose adding a function to the mysql pdo driver (in the same
way postgres and sqlite have) to extract the count of warnings from the
last executed statement.
See the pull request linked above for a more thorough description.
Should I make an RFC out of this?
Thanks for your time!
Daniel Beardsley
> I think having the behaviour of language features depend in an incompatible
> way on a global runtime setting is a bad idea because it creates nonlocal
> effects and means code cannot be realiably composed.
This is probably the best argument against this RFC. Though how often
that issue would co
> The similarity is that magic quotes assumed that the input data was going to
> be embedded within an SQL query without escaping, and therefore needed
> escaping. Of course that's an invalid assumption, the input data could be
> re-rendered, processed in some arbitrary way, written to a file, sent
> Wouldn't this __auto_escape setting effectively break libraries that depend
> on it being on or off?
The settings was meant to be turned on *only* during template
rendering. So, yes, if outside code is run during your template
rendering that also uses templating, but is unaware of
auto escaping,
> Issue is "Escaping is done on a specific context".
>
> I understand your proposal is focused on HTML escaping. However,
> setting names like
> __auto_escape_exempt_class
> is not good choice. It has to be
> __auto_html_escape_exempt_class
> at least because it is for HTML escaping.
Yes, the ini
> I agree XHP really is the right solution for this problem. It enables HTML
> to be created structurally and composably with a concise inline syntax, just
> like JSX/React does for JavaScript, and just like LINQ does for SQL in C#.
> It's much better than passing around snippets of HTML as strings
> > T_ECHO (echo, > ZEND_AST_ECHO_ESCAPE node in the syntax tree.
> >
> Interesting approach, I assume an explicit `echo $foo;` takes the
> normal ZEND_ECHO route then?
No, looking at the code and tests: echo, print, and > Which allows instances of `HtmlString` to pass straight through a
> > tem
the html_entities call).
Helper functions can now return html safely and consumers don't have
to care if it is HTML or not because the auto-escaping system knows
what to do.
Thanks for your consideration!
Daniel Beardsley
12 matches
Mail list logo
