On Fri, Jan 09, 2015 at 02:54:56PM -, Greg Sabino Mullane wrote:
Just a heads up to this list - support for backslash-escaped placeholders
is now implemented in the current production version of DBD::Pg, 3.5.0
http://search.cpan.org/dist/DBD-Pg/
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Just a heads up to this list - support for backslash-escaped placeholders
is now implemented in the current production version of DBD::Pg, 3.5.0
http://search.cpan.org/dist/DBD-Pg/
http://cpansearch.perl.org/src/TURNSTEP/DBD-Pg-3.5.0/Changes
On Wed, Dec 31, 2014 at 03:55:42AM -, Greg Sabino Mullane wrote:
Tim Bunce wrote:
Wherein I attempt to summarize the requirements, the background, the
options,
the risks, and the counter-proposal ...
Thanks for taking the time to write all this out in a coherent manner.
You're
Hi All
My apologies. Instead of Text::Balanced::Marpa, I should have pointed
you to MarpaX::Languages::SQL2003::AST.
Here, AST is Abstract syntax tree. See
https://en.wikipedia.org/wiki/Abstract_syntax_tree.
--
Ron Savage - savage.net.au
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tim Bunce wrote:
Wherein I attempt to summarize the requirements, the background, the options,
the risks, and the counter-proposal ...
Thanks for taking the time to write all this out in a coherent manner.
I may once again assume the role of
On Dec 28, 2014, at 5:49 AM, Tim Bunce tim.bu...@pobox.com wrote:
Question marks are the international standard for placeholders.
The DBI should have specified a way to escape them from the start.
I'm attempting to fix that now.
+1
David
smime.p7s
Description: S/MIME cryptographic
a placeholder, to appear in the SQL without it being
treated as a placeholder by the driver. To escape it's usual meaning.
If escaping question mark placeholders was already defined in 2008 then
pg_placeholder_dollaronly might not have been added to DBD::Pg.
The issue of escaping placeholders
Thank you for this post Tim, it seemed to lay out the issues well and make a lot
of things clear.
I'm now inclined to support your backslash-escape proposal at the DBI driver
level in principle.
(I also agree that the doubling method is nasty.)
Or alternately I suggest variation on that
Hi Darren
On 29/12/14 13:59, Darren Duncan wrote:
The API could involve an 'attr' given when preparing a SQL statement or
other appropriate places.
placeholder_escape_delimiters = [ '\{','}' ]
placeholder_escape_delimiters = [ '\{','}','\[',']' ]
placeholder_escape_delimiters = [
Sometime over the holiday period I hope to write up a summary of the
arguments for and against and suggest ways forwards.
Tim.
On 22/12/2014 00:39, Darren Duncan wrote:
I agree with Greg's counter-proposal, from which I derive my own words
here.
1. I propose that there be no modification to the DBI spec related to
new escaping whether optional or not, so leave things the way they are
here, SQL continues to be
On 12/20/2014 03:38 PM, Tim Bunce wrote:
On Fri, Dec 19, 2014 at 01:12:16PM +0100, Alexander Foken wrote:
Hello all,
this reminds me of a similar problem I had in 2000 with DBI,
DBD::Oracle, and Oracle. See
http://marc.info/?t=9506395904r=1w=2,
Am 20.12.2014 um 23:10 schrieb Tim Bunce tim.bu...@pobox.com:
On Sat, Dec 20, 2014 at 05:35:55PM +0100, Alexander Foken wrote:
On 20.12.2014 15:38, Tim Bunce wrote:
Can you, or anyone else, think of any situation where a backslash before
a ? or :foo (or even $1) style placeholder might be
On 20.12.2014 15:38, Tim Bunce wrote:
[...]
Can you, or anyone else, think of any situation where a backslash before
a ? or :foo (or even $1) style placeholder might be valid SQL?
Inside quoted text: of course, yes.
Outside quoted text: maybe some RDBMS accept a backslash as a valid character
code, I will survive �� like I have for the
last decade and more. Just
make sure that whatever you do does not break working valid Informix SQL
code.
I have absolutely no intention of breaking anything :)
It'll be up to the individual driver authors to add support for escaping
placeholders
On 20.12.2014 23:10, Tim Bunce wrote:
On Sat, Dec 20, 2014 at 05:35:55PM +0100, Alexander Foken wrote:
On 20.12.2014 15:38, Tim Bunce wrote:
Can you, or anyone else, think of any situation where a backslash before
a ? or :foo (or even $1) style placeholder might be valid SQL?
[...]
Do you
On Sun, Dec 21, 2014 at 10:27:18AM +0100, pe...@vanroose.be wrote:
On 20.12.2014 15:38, Tim Bunce wrote:
[...]
Can you, or anyone else, think of any situation where a backslash before
a ? or :foo (or even $1) style placeholder might be valid SQL?
Inside quoted text: of course, yes.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tim Bunce wrote:
For code not using DBIx::Class the pg_placeholder_dollaronly attribute
might work, see https://metacpan.org/pod/DBD::Pg#Placeholders
Yes, this is the current canonical solution. It's a real shame
that ? was used as an
I agree with Greg's counter-proposal, from which I derive my own words here.
1. I propose that there be no modification to the DBI spec related to new
escaping whether optional or not, so leave things the way they are here, SQL
continues to be interpreted the way it long has by default.
2.
Thanks David :)
Tim.
On Fri, Dec 19, 2014 at 12:23:23PM -0600, David Nicol wrote:
Please disregard my previous. After reading Tim Bunce's earlier response
and thinking about this some
more, although backslash escaping can be tricky, that is how Perl does
these things, and Perl coders
On Fri, Dec 19, 2014 at 01:12:16PM +0100, Alexander Foken wrote:
Hello all,
this reminds me of a similar problem I had in 2000 with DBI,
DBD::Oracle, and Oracle. See
http://marc.info/?t=9506395904r=1w=2,
http://173.79.223.25/?l=dbi-devm=95077716125217w=2.
Problem was using named
On 20.12.2014 15:38, Tim Bunce wrote:
On Fri, Dec 19, 2014 at 01:12:16PM +0100, Alexander Foken wrote:
Hello all,
this reminds me of a similar problem I had in 2000 with DBI,
DBD::Oracle, and Oracle. See
http://marc.info/?t=9506395904r=1w=2,
Many, many years ago, DBD::Informix had to give up on the DBI-provided
parsing for placeholders because there were too many contexts in which it
was wrong for Informix. It may have improved since then, but:
INSERT INTO SomeTable(DateTimeCol)
VALUES(DATETIME(2014-12-31 23:59:59) YEAR
On Sat, Dec 20, 2014 at 05:35:55PM +0100, Alexander Foken wrote:
On 20.12.2014 15:38, Tim Bunce wrote:
Can you, or anyone else, think of any situation where a backslash before
a ? or :foo (or even $1) style placeholder might be valid SQL?
I found two situations for PostgreSQL:
(1)
On Sat, Dec 20, 2014 at 01:14:29PM -0800, Jonathan Leffler wrote:
Many, many years ago, DBD::Informix had to give up on the DBI-provided
parsing for placeholders because
there were too many contexts in which it was wrong for Informix. It may
have improved since then, but:
Gmail hid the line you gave (as if it was the same as something I'd sent —
curious behaviour by Gmail):
INSERT INTO SomeTable(DateTimeCol)
VALUES(DATETIME(2014-12-31 23\:59\:59) YEAR TO SECOND);
I really won't want people have to futz with their legitimate Informix SQL
in order to
Hello Augustus.
On Thu, Dec 04, 2014 at 03:38:14PM -0800, Augustus Saunders wrote:
Hi all, I have been unable to find a way to use some of the new
JSONB operators in Postgres 9.4 with DBIx::Class. A quick search
for JSONB on the email archive site didn't turn up any results, so
I
Hello all,
this reminds me of a similar problem I had in 2000 with DBI,
DBD::Oracle, and Oracle. See
http://marc.info/?t=9506395904r=1w=2,
http://173.79.223.25/?l=dbi-devm=95077716125217w=2.
Problem was using named placeholders (:foo) in DBI and at the same
time use PL/SQL code
On Fri, Dec 19, 2014 at 6:12 AM, Alexander Foken alexan...@foken.de wrote:
Problem was using named placeholders (:foo) in DBI and at the same time
use PL/SQL code containing variables (:bar), DBI considered both :foo
and :bar to be placeholders instead of leaving :bar alone and pass it
to
Please disregard my previous. After reading Tim Bunce's earlier response
and thinking about this some more, although backslash escaping can be
tricky, that is how Perl does these things, and Perl coders are familiar
with the nuances of when they must be doubled to get through quoting.
Doubling of
30 matches
Mail list logo
