ikegami@adaelis.com via RT wrote:
Show quoted text> Queue: SQL-Statement
> Ticket <URL:
http://rt.cpan.org/Ticket/Display.html?id=34121 >
>
> On Sat, Jan 3, 2009 at 2:35 AM, dubzed <dubzed@gmail.com> wrote:
>
>
>> Eric Brine wrote:
>>
>>
> No it doesn't. The attached test works with a column named q{"has space"},
>
>>> not q{has space}
>>>
>>>
>> You are talking about what the column is named in the text file. I am
>> talking about how the column is referred to in the syntax. One of the
>> points of S::S is to allow similar kinds of syntax to be used as is used in
>> other implementations. It accomplishes that. Because you don't like how
>> the resulting text file looks has nothing to do with how well or poorly the
>> SQL syntax is implemented.
>>
>
>
> This bug report is not about the syntax. I don't know why you keep bringing
> that up.
>
>
Because we are discussing S::S whose purpose is to provide SQL syntax
support. It is used for many purposes only some of which apply to
DBD::CSV - other DBDs, parsing of SQL dumps, etc. And what you are
reporting is not symantics, it is an internal storage detail.
Show quoted text> Are you saying the problem is in DBD::CSV, that it should parse the SQL
> identifier to extract the column name?
>
>
>
>> ---BEGIN---
>>
>>> """name with spaces""","""text"""
>>> 3,bar
>>> ---END---
>>>
>>> should be
>>>
>>> ---BEGIN---
>>> "name with spaces","text"
>>> 3,bar
>>> ---END---
>>>
>>>
>>>
>> If it was that way, when S::S opened the file, how would it know that it
>> should not object to "name with spaces' - or do you want it not to check for
>> valid names at all?
>>
>>
>
> I don't understand the question.
> S::S should object to column names it can't handle.
> S::S shouldn't object to column names it can handle.\
>
That's absurd. SQL Statement should behave like every other RDBMS in
this respect - it should not accept identifiers that are not valid in
the SQL standard. It should tell the user their syntax is broken and
refuse to use them. Otherwise it would be completely incompatible with
other RDBMSs.
Show quoted text> q{name with spaces} is a valid column name.
>
No it is not a SQL '92 valid column unless it is delimited. In what
possible sense could you use the word "valid" for it?
Show quoted text> It would appear as q{"name with spaces"} in a CSV file, but S::S need not
> ever know that.
>
No it can't appear like that in the file. If it appears like that in
the file there is no way for S::S to treat it as a valid identifier
because it isn't one. (well it can appear in the file but you can't
expect S::S to handle it unless you munge it first).
Show quoted text> It would appear as q{"name with spaces"} in an SQL statement.
>
> Do you really not know the difference between a literal and an identifier?
>
Do you really not know the difference between a SQL valid identifier and
one that isn't?
--
Jeff
Show quoted text> In Perl, "foo bar" is a 9 character literal that represents a 7 character
> long string.
> In CSV, "foo bar" is a 9 character literal that represents a 7 character
> long column name.
> In SQL, "foo bar" is a 9 character literal that represents a 7 character
> long column name.
> In S::S, "foo bar" is a 9 character literal that represents a 9 character
> long column name.
> This is the bug I'm reporting.
>
> Eric "ikegami" Brine
>
>
>
> ------------------------------------------------------------------------
>
>
>
> On Sat, Jan 3, 2009 at 2:35 AM, dubzed <dubzed@gmail.com
> <mailto:dubzed@gmail.com>> wrote:
>
> Eric Brine wrote:
>
> No it doesn't. The attached test works with a column named
> q{"has space"}, not q{has space}
>
>
> You are talking about what the column is named in the text file.
> I am talking about how the column is referred to in the syntax.
> One of the points of S::S is to allow similar kinds of syntax to
> be used as is used in other implementations. It accomplishes
> that. Because you don't like how the resulting text file looks
> has nothing to do with how well or poorly the SQL syntax is
> implemented.
>
>
> This bug report is not about the syntax. I don't know why you keep
> bringing that up.
>
> Are you saying the problem is in DBD::CSV, that it should parse the
> SQL identifier to extract the column name?
>
>
> ---BEGIN---
> """name with spaces""","""text"""
> 3,bar
> ---END---
>
> should be
>
> ---BEGIN---
> "name with spaces","text"
> 3,bar
> ---END---
>
>
> If it was that way, when S::S opened the file, how would it know
> that it should not object to "name with spaces' - or do you want
> it not to check for valid names at all?
>
>
> I don't understand the question.
> S::S should object to column names it can't handle.
> S::S shouldn't object to column names it can handle.
>
> q{name with spaces} is a valid column name.
> It would appear as q{"name with spaces"} in a CSV file, but S::S need
> not ever know that.
> It would appear as q{"name with spaces"} in an SQL statement.
>
> Do you really not know the difference between a literal and an identifier?
> In Perl, "foo bar" is a 9 character literal that represents a 7
> character long string.
> In CSV, "foo bar" is a 9 character literal that represents a 7
> character long column name.
> In SQL, "foo bar" is a 9 character literal that represents a 7
> character long column name.
> In S::S, "foo bar" is a 9 character literal that represents a 9
> character long column name.
> This is the bug I'm reporting.
>
> Eric "ikegami" Brine
>
