Skip Menu |

This queue is for tickets about the SQL-Statement CPAN distribution.

Report information
The Basics
Id: 71506
Status: rejected
Priority: 0/
Queue: SQL-Statement

People
Owner: Nobody in particular
Requestors: BitCard [...] ResonatorSoft.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: Bad table or column name: '274822' starts with non-alphabetic character!
Currently, I'm trying to make a DBD::FusionTables module. Some of the code requires parsing the statement to figure out all of the fields and characteristics. However, Google Fusion Tables use pure numbers for table "names", and thus spawns the above error. This error comes from SQL::Parser::IDENTIFIER. Unfortunately, the sub is hard-coded with the proper types of characters. Furthermore, IDENTIFIER plays favorites with CSV with the following exception: # CSV requires optional start with _ my $badStartRx = uc( $self->{dialect} ) eq 'ANYDATA' ? qr/^\d/ : qr/^[_\d]/; These kind of exceptions should be taken out of the hard-code and put into either the Dialect module or as some sort of extra variable. As it is now, I'm going to have to overwrite the SQL::Parser::IDENTIFIER as a fix.
On Thu Oct 06 13:29:46 2011, SineSwiper wrote: Show quoted text
> Currently, I'm trying to make a DBD::FusionTables module.
Great \o/ Show quoted text
> Some of the > code requires parsing the statement to figure out all of the fields and > characteristics. However, Google Fusion Tables use pure numbers for > table "names", and thus spawns the above error.
If I understand SQL correctly, it's not allowed to use pure numbers as identifier names (nor it's allowed to start identifiers with a number). Show quoted text
> This error comes from SQL::Parser::IDENTIFIER. Unfortunately, the sub > is hard-coded with the proper types of characters.
With look into SQL standard description, there is no room to play with many options ... Show quoted text
> Furthermore, > IDENTIFIER plays favorites with CSV with the following exception: > > # CSV requires optional start with _ > my $badStartRx = uc( $self->{dialect} ) eq 'ANYDATA' ? qr/^\d/ : > qr/^[_\d]/; > > These kind of exceptions should be taken out of the hard-code and put > into either the Dialect module or as some sort of extra variable. As it > is now, I'm going to have to overwrite the SQL::Parser::IDENTIFIER as
a fix. If you would provide an appropriate fix to move such exceptions into the dialect code, I'm glad to review and hopefully accept it. OTOH it might be reasonable to force the users to quote invalid sql identifiers ... Best regards, Jens
On Fri Oct 07 04:16:45 2011, REHSACK wrote: Show quoted text
> If I understand SQL correctly, it's not allowed to use pure numbers as > identifier names (nor it's allowed to start identifiers with a number).
FusionTables is, errr, different. The SQL is limited, doesn't support JOINs, and allows for just about any character in a name (as long as it's in quotes). But, yeah, the table names are purely numbers. I'm mostly using SQL::Statement for parameter counting/parsing. As I understand, SQL doesn't allow for names to start with underscore, either :) Show quoted text
> If you would provide an appropriate fix to move such exceptions into the > dialect code, I'm glad to review and hopefully accept it. OTOH it might > be reasonable to force the users to quote invalid sql identifiers ...
Sure thing. I'd rather patch the right function than overload it on my end. For reference, here's the overloaded change, though: # CSV requires optional start with _ my $badStartRx = uc($self->{dialect}) eq 'ANYDATA' ? qr/^\d/ : qr/^[_\d]/; # FusionTables requires all numbers in tables, and has no StartRx requirements $badStartRx = uc($self->{dialect}) eq 'FUSIONTABLES' ? qr/^\W/ : $badStartRx;
No new arguments and wish violates ANSI SQL.