gmane.comp.db.postgresql.dbdpg

DBD::Pg version 2.19.1 released

Greg Sabino Mullane — 2012-03-11T23:00:37

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Version 2.19.1 of DBD::Pg, the Perl interface to PostgreSQL, 
has just been released. This (and 2.19.0) fixes some serious 
bugs, so upgrading is recommended for all users. You can 
find it at your local CPAN mirror, or at:

http://search.cpan.org/~turnstep/DBD-Pg-2.19.1/

Checksums, MD5 and SHA1:

3a86ac826f5285003b87c6a8b225e0c4  DBD-Pg-2.19.1.tar.gz
0d0bd7daf2c24758716fbbde686e4d66cf81a206  DBD-Pg-2.19.1.tar.gz

Complete list of changes for 2.19.0 and 2.19.1:

  - Fix crash when passing in an array with undefined elements. [GSM]

  - Use proper formatting for warn() and croak() (CPAN bug #75642)
    [Niko Tyni]

  - Fix localized regex in test (CPAN bug #70759)

  - Fix for named placeholders (CPAN bug #70953) [Jan Pazdziora]

  - Various fixes to the array-marshalling code [Noah Misch, Mark 
    Stosberg, and David Christensen] (CPAN bug #58552)

  - Allow hi-bit chars in dollar-quoted identifiers 
    [David Christensen] (CPAN bug #73832)

  - Have do

feature request

Манол Ружинов — 2012-02-03T16:52:23

Hi,
I need to get the type for a column from query result, but for
Postgres user defined types (composite types) I cannot find DBD::Pg
field  that contains such a  info.
For example for the query:
select A as class_record from pg_class A;

in the resulting DBI statement I have:
$$sth{TYPE}[0]: 0
$$sth{pg_type}[0]: 'unknown'

when the pqlib call PQftype() returns actual OID of the pg_class type.

Currently all calls to  PQftype() are wrapped around pg_type_data()
(for example  pg_type_data((int)PQftype(imp_sth->result, fields)), and
 pg_type_data() always returns NULL if the type is not standard.

I think if the result of PQftype() can be stored in a new pg specific
field (for example pg_type_oid) this will give a way of using composit
types without changing current behavior of the driver ?

Best regards!
Manol

Re: [DBD::Pg] allow hi-bit chars in dollar-quoted identifiers

David E. Wheeler — 2012-01-17T20:11:40


Excellent, thank you. Would be get to get a release out with these fixes.

What’s the status of the UTF-8 stuff?

David

Re: [DBD::Pg] allow hi-bit chars in dollar-quoted identifiers

David Christensen — 2012-01-17T20:10:04

Committed.

At some point in the near future I'm going to revert the utf8 changes in the master branch until things are resolved with the unicode changes.

Regards,

David
--
David Christensen
End Point Corporation
david-O9fzpki4YnJWk0Htik3J/w< at >public.gmane.org

Re: [DBD::Pg] allow hi-bit chars in dollar-quoted identifiers

David E. Wheeler — 2012-01-17T18:37:37


Oh, awesomesauce, thanks!

David

Re: [DBD::Pg] allow hi-bit chars in dollar-quoted identifiers

David Christensen — 2012-01-17T18:34:35

On Jan 12, 2012, at 11:15 PM, David E. Wheeler wrote:



Hi David,

I created a new branch for the utf-8 stuff in the main repo.  I'll review/commit this to master shortly.

Regards,

David
--
David Christensen
End Point Corporation
david-O9fzpki4YnJWk0Htik3J/w< at >public.gmane.org

Re: [DBD::Pg] allow hi-bit chars in dollar-quoted identifiers

David E. Wheeler — 2012-01-13T05:15:21


Sorry, I meant this:

  https://rt.cpan.org/Ticket/Display.html?id=58552

Best,

David

Re: [DBD::Pg] allow hi-bit chars in dollar-quoted identifiers

David E. Wheeler — 2012-01-13T05:14:53


Is this in a branch separate from the Unicode stuff? If so, care to also commit this?

  https://rt.cpan.org/Ticket/Display.html?id=72551

Best,

David

Re: Inconsistent behaviour with Dollar-quoted String Constants

David Christensen — 2012-01-09T04:22:39

Proposed patch:

commit 830ba62d179fca2ccf01d7900aa58676a4a17f9c
Author: David Christensen <david-O9fzpki4YnJWk0Htik3J/w< at >public.gmane.org>
Date:   Sun Jan 8 22:16:40 2012 -0600

    allow hi-bit chars in dollar-quoted identifiers

diff --git a/dbdimp.c b/dbdimp.c
index 0c1d22f..b6f1235 100644
--- a/dbdimp.c
+++ b/dbdimp.c
< at >< at > -1785,12 +1785,12 < at >< at > static void pg_st_split_statement (pTHX_ imp_sth_t * imp_sth, int version, char
                        (*statement == '$' 
                         || *statement == '_'
                         || (*statement >= 'A' && *statement <= 'Z') 
-                        || (*statement >= 'a' && *statement <= 'z'))) {
+                        || (*statement >= 'a' && *statement <= 'z')
+                        || ((unsigned char)*statement >= (unsigned char)'\200'))) {
                        /* "SQL identifiers must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) 
                 or an underscore (_). Subsequent characters in an id

Re: Inconsistent behaviour with Dollar-quoted String Constants

David E. Wheeler — 2012-01-09T03:28:15


Thanks, added to the ticket.

  https://rt.cpan.org/Ticket/Display.html?id=73832

Best,

Davd

Re: Inconsistent behaviour with Dollar-quoted String Constants

Andrew Dunstan — 2012-01-08T23:33:12


On 01/08/2012 03:51 PM, David E. Wheeler wrote:

Any non-ASCII character qualifies. From scan.l:

    dolq_start      [A-Za-z\200-\377_]
    dolq_cont       [A-Za-z\200-\377_0-9]
    dolqdelim       \$({dolq_start}{dolq_cont}*)?\$


cheers

andrew

Re: Inconsistent behaviour with Dollar-quoted String Constants

David E. Wheeler — 2012-01-08T20:51:18


It probably wouldn’t if you passed parameters to it.

Anyway, the ppg docs](http://www.postgresql.org/docs/9.1/static/sql-syntax-lexical.html) say about dollar quoting:

“The tag, if any, of a dollar-quoted string follows the same rules as an unquoted identifier, except that it cannot contain a dollar sign.”

And for an unquoted identifier, they say:

“SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_). Subsequent characters in an identifier or key word can be letters, underscores, digits (0-9), or dollar signs ($).”

Does 北 qualify as a non-Latin letter? If you can create a table with that character, it’s valid. I just tried:

    CREATE TABLE 北 (it int);

And it worked. So this looks like a bug in DBD::Pg, which recognizes dollar quoting when it parses for placeholders, but not to the letter of the documentation, I guess.

Would you mind reporting this bug by sending an email to bug-dbd-pg-ROqZdf

Inconsistent behaviour with Dollar-quoted String Constants

2012-01-07T14:49:05

Hello,

I am using UTF-8 characters within Dollar-quoted tags.
Following code is the problem-setting.

--- CODE BEGIN ---
#!/usr/bin/perl
use strict; use DBI;
my $db = DBI->connect(
     "dbi:Pg:dbname=$PgDbName;host=$PgHost;port=$PgPort",
     $PgSqlUser, $PgSqlPass);

my $txt = '2';
my $delim = "\$\x{5317}\$";

my $sql = "SELECT $delim$txt$delim";
print "SQL = '$sql'\n";
$db->do($sql);
print "after do\n";
$db->selectrow_hashref($sql);
print "after_selectrow_hashref\n";
--- CODE END ---

The script dies during selectrow_hashref and the output of the script is

--- OUTPUT BEGIN ---
SQL = 'SELECT $北$2$北$'
after do
Invalid placeholders: must start at $1 and increment one at a time 
(expected: $1)
--- OUTPUT END ---

It seems like $2 is interpreted as placeholder before the evaluation of 
Dollar-quoting, but only in $db->selectrow_hashref().
The inconsistent part is that $db->do() works just fine.

Regards,
Markus

System: Debian sid with libdbd-pg-perl 2.18.1-1+b1 and perl 5.14.2-6

Re: Inconsistent behaviour with Dollar-quoted String Constants

David Christensen — 2012-01-09T04:22:39

Proposed patch:

commit 830ba62d179fca2ccf01d7900aa58676a4a17f9c
Author: David Christensen <david-O9fzpki4YnJWk0Htik3J/w< at >public.gmane.org>
Date:   Sun Jan 8 22:16:40 2012 -0600

    allow hi-bit chars in dollar-quoted identifiers

diff --git a/dbdimp.c b/dbdimp.c
index 0c1d22f..b6f1235 100644
--- a/dbdimp.c
+++ b/dbdimp.c
< at >< at > -1785,12 +1785,12 < at >< at > static void pg_st_split_statement (pTHX_ imp_sth_t * imp_sth, int version, char
                        (*statement == '$' 
                         || *statement == '_'
                         || (*statement >= 'A' && *statement <= 'Z') 
-                        || (*statement >= 'a' && *statement <= 'z'))) {
+                        || (*statement >= 'a' && *statement <= 'z')
+                        || ((unsigned char)*statement >= (unsigned char)'\200'))) {
                        /* "SQL identifiers must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) 
                 or an underscore (_). Subsequent characters in an id

Re: Inconsistent behaviour with Dollar-quoted String Constants

David E. Wheeler — 2012-01-09T03:28:15


Thanks, added to the ticket.

  https://rt.cpan.org/Ticket/Display.html?id=73832

Best,

Davd

Re: Inconsistent behaviour with Dollar-quoted String Constants

Andrew Dunstan — 2012-01-08T23:33:12


On 01/08/2012 03:51 PM, David E. Wheeler wrote:

Any non-ASCII character qualifies. From scan.l:

    dolq_start      [A-Za-z\200-\377_]
    dolq_cont       [A-Za-z\200-\377_0-9]
    dolqdelim       \$({dolq_start}{dolq_cont}*)?\$


cheers

andrew

Re: Inconsistent behaviour with Dollar-quoted String Constants

David E. Wheeler — 2012-01-08T20:51:18


It probably wouldn’t if you passed parameters to it.

Anyway, the ppg docs](http://www.postgresql.org/docs/9.1/static/sql-syntax-lexical.html) say about dollar quoting:

“The tag, if any, of a dollar-quoted string follows the same rules as an unquoted identifier, except that it cannot contain a dollar sign.”

And for an unquoted identifier, they say:

“SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_). Subsequent characters in an identifier or key word can be letters, underscores, digits (0-9), or dollar signs ($).”

Does 北 qualify as a non-Latin letter? If you can create a table with that character, it’s valid. I just tried:

    CREATE TABLE 北 (it int);

And it worked. So this looks like a bug in DBD::Pg, which recognizes dollar quoting when it parses for placeholders, but not to the letter of the documentation, I guess.

Would you mind reporting this bug by sending an email to bug-dbd-pg-ROqZdf

Inconsistent behaviour with Dollar-quoted String Constants

2012-01-07T14:49:05

Hello,

I am using UTF-8 characters within Dollar-quoted tags.
Following code is the problem-setting.

--- CODE BEGIN ---
#!/usr/bin/perl
use strict; use DBI;
my $db = DBI->connect(
     "dbi:Pg:dbname=$PgDbName;host=$PgHost;port=$PgPort",
     $PgSqlUser, $PgSqlPass);

my $txt = '2';
my $delim = "\$\x{5317}\$";

my $sql = "SELECT $delim$txt$delim";
print "SQL = '$sql'\n";
$db->do($sql);
print "after do\n";
$db->selectrow_hashref($sql);
print "after_selectrow_hashref\n";
--- CODE END ---

The script dies during selectrow_hashref and the output of the script is

--- OUTPUT BEGIN ---
SQL = 'SELECT $北$2$北$'
after do
Invalid placeholders: must start at $1 and increment one at a time 
(expected: $1)
--- OUTPUT END ---

It seems like $2 is interpreted as placeholder before the evaluation of 
Dollar-quoting, but only in $db->selectrow_hashref().
The inconsistent part is that $db->do() works just fine.

Regards,
Markus

System: Debian sid with libdbd-pg-perl 2.18.1-1+b1 and perl 5.14.2-6

Re: Inconsistent behaviour with Dollar-quoted String Constants

Andrew Dunstan — 2012-01-08T23:33:12


On 01/08/2012 03:51 PM, David E. Wheeler wrote:

Any non-ASCII character qualifies. From scan.l:

    dolq_start      [A-Za-z\200-\377_]
    dolq_cont       [A-Za-z\200-\377_0-9]
    dolqdelim       \$({dolq_start}{dolq_cont}*)?\$


cheers

andrew

Re: Inconsistent behaviour with Dollar-quoted String Constants

David E. Wheeler — 2012-01-08T20:51:18


It probably wouldn’t if you passed parameters to it.

Anyway, the ppg docs](http://www.postgresql.org/docs/9.1/static/sql-syntax-lexical.html) say about dollar quoting:

“The tag, if any, of a dollar-quoted string follows the same rules as an unquoted identifier, except that it cannot contain a dollar sign.”

And for an unquoted identifier, they say:

“SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_). Subsequent characters in an identifier or key word can be letters, underscores, digits (0-9), or dollar signs ($).”

Does 北 qualify as a non-Latin letter? If you can create a table with that character, it’s valid. I just tried:

    CREATE TABLE 北 (it int);

And it worked. So this looks like a bug in DBD::Pg, which recognizes dollar quoting when it parses for placeholders, but not to the letter of the documentation, I guess.

Would you mind reporting this bug by sending an email to bug-dbd-pg-ROqZdf

Inconsistent behaviour with Dollar-quoted String Constants

2012-01-07T14:49:05

Hello,

I am using UTF-8 characters within Dollar-quoted tags.
Following code is the problem-setting.

--- CODE BEGIN ---
#!/usr/bin/perl
use strict; use DBI;
my $db = DBI->connect(
     "dbi:Pg:dbname=$PgDbName;host=$PgHost;port=$PgPort",
     $PgSqlUser, $PgSqlPass);

my $txt = '2';
my $delim = "\$\x{5317}\$";

my $sql = "SELECT $delim$txt$delim";
print "SQL = '$sql'\n";
$db->do($sql);
print "after do\n";
$db->selectrow_hashref($sql);
print "after_selectrow_hashref\n";
--- CODE END ---

The script dies during selectrow_hashref and the output of the script is

--- OUTPUT BEGIN ---
SQL = 'SELECT $北$2$北$'
after do
Invalid placeholders: must start at $1 and increment one at a time 
(expected: $1)
--- OUTPUT END ---

It seems like $2 is interpreted as placeholder before the evaluation of 
Dollar-quoting, but only in $db->selectrow_hashref().
The inconsistent part is that $db->do() works just fine.

Regards,
Markus

System: Debian sid with libdbd-pg-perl 2.18.1-1+b1 and perl 5.14.2-6