Discussion:
feature request for SQL::Statement::Structure
(too old to reply)
Jens Rehsack
2012-04-07 07:30:27 UTC
Permalink
Greetings,
I am wanting to take a SELECT statement and change the names of the
tables without IMMEDIATELY executing that statement. I was hoping that
SQL::Statement would solve the problem but apparently it can only
EXECUTE a statement. Is this true? I could not find anywhere that
deemed contrary in either the docs nor the source code.
Seems to me that a lot of value is to be found in parsing statements,
changing them and then PRINTING them out or storing them as scalars
for execution at a later time.  Would you be so kind as to provide
this functionality? I honestly do not see any reason why it was not
made available from the first release of this code.
Sorry for the tone, but i was highly disappointed to learn that such a
valuable and simple function was left out during my evaluation of this
software. We will most likely use an alternative, but maybe the next
person will not have to. Thanks in advance.
Hey Jeff,

please either open a ticket using RT or discuss it on dbi-dev@ or
probably dbi-***@. For now, I cc dbi-***@. For feature
requests, cc'ing dbi-dev@ is always a good idea.

To your mail itself: I absolutely don't know what you're talking about.
No version information, nothing about the OS/distribution you use.
No test describing what you're doing and what's failing.

Probably you can fix this and after that worry about your tone ;)

Best regards,
Jens
H.Merijn Brand
2012-04-07 07:45:03 UTC
Permalink
On Sat, 7 Apr 2012 08:30:27 +0100, Jens Rehsack
Post by Jens Rehsack
Greetings,
I am wanting to take a SELECT statement and change the names of the
tables without IMMEDIATELY executing that statement. I was hoping that
SQL::Statement would solve the problem but apparently it can only
EXECUTE a statement. Is this true? I could not find anywhere that
deemed contrary in either the docs nor the source code.
Seems to me that a lot of value is to be found in parsing statements,
changing them and then PRINTING them out or storing them as scalars
for execution at a later time.  Would you be so kind as to provide
this functionality? I honestly do not see any reason why it was not
made available from the first release of this code.
Sorry for the tone, but i was highly disappointed to learn that such a
valuable and simple function was left out during my evaluation of this
software. We will most likely use an alternative, but maybe the next
person will not have to. Thanks in advance.
Hey Jeff,
To your mail itself: I absolutely don't know what you're talking about.
Me neither. What /could/ help is a snippet of code that would do what
you'd expect it to do as if SQL::Statement already supports what you
want it to do.
Post by Jens Rehsack
No version information, nothing about the OS/distribution you use.
No test describing what you're doing and what's failing.
Probably you can fix this and after that worry about your tone ;)
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Jens Rehsack
2012-04-07 14:10:32 UTC
Permalink
Post by Jens Rehsack
Greetings,
I am wanting to take a SELECT statement and change the names of the
tables without IMMEDIATELY executing that statement. I was hoping that
SQL::Statement would solve the problem but apparently it can only
EXECUTE a statement. Is this true? I could not find anywhere that
deemed contrary in either the docs nor the source code.
Seems to me that a lot of value is to be found in parsing statements,
changing them and then PRINTING them out or storing them as scalars
for execution at a later time.  Would you be so kind as to provide
this functionality? I honestly do not see any reason why it was not
made available from the first release of this code.
Sorry for the tone, but i was highly disappointed to learn that such a
valuable and simple function was left out during my evaluation of this
software. We will most likely use an alternative, but maybe the next
person will not have to. Thanks in advance.
Hey Jeff,
To your mail itself: I absolutely don't know what you're talking about.
No version information, nothing about the OS/distribution you use.
No test describing what you're doing and what's failing.
Probably you can fix this and after that worry about your tone ;)
Don't worry about it ... i just wanted confirmation that you really
didn't think to have such a valuable feature.
Well, I don't know - because I don't understand what you want.
But a "do what I mean" feature is indeed missing. Patches welcome.
I will "fix this" by simply not using your code. :)
Well, great fix. I'm going to recommend it further.

Impressive things in volunteer projects is that so many people
kindly provide ideas, fixes and improvements.

Thank you very much helping to improve SQL::Statement,
Jens
Reinier Post
2012-04-07 16:02:26 UTC
Permalink
I think I do understand, if it's the same thing that I initially
expected when I read that SQL statements are SQL::Statement objects.

SQL::Statement can parse and interpret SQL statements.
It would be useful to expose an object model for parsed statements
allowing the user to read, modify, and create such statements
without having to go through the asinine duty of getting the
surface syntax for those statements right.

Completely hypothetical example:

use SQL::Expression::ColumnValued qw(avg count first distinct column);
use SQL::Expression::TableValued qw(table, natural_join);

my $stmt = new SQL::Statement::Select(
{
yield =>
[ avg(column('salary')), count(distinct(column('firstname'))),
column('lastname') ],
from =>
[ natural_join(table('employee'), table('salry')) ]
group_by =>
[ column('lastname') ]
});

$stmt->to_string # is:
# SELECT AVG(salary), COUNT(DISTINCT(firstname)), lastname
# FROM employee NATURAL JOIN salry
# GROUP BY lastname

$stmt->from->join[1]->column = 'salary';
push($stmt->yield, first(column('firstname')));

$stmt->to_string # is now:
# SELECT AVG(salary), COUNT(DISTINCT(firstname)), lastname,
# FIRST (firstname)
# FROM employee NATURAL JOIN salary
# GROUP BY lastname

$stmt->execute()

This would get rid of the need to properly escape arbitrary table
and column names, and it might also perform sophisticated syntax
checking and validity checking against a given schema.

It's like prepare() but taking the idea to another level.

It's not all that useful, however, to have this in SQL::Statement,
because it would only work for those DBI backends that use it.
What I really want is something like this as a generic,
backend-independent interface to SQL, and that is not at all
what SQL::Statement, or DBI for that matter, tries to provide.
Some other DBI-based modules do take some steps in that direction.
--
Reinier Post
Reinier Post
2012-04-07 16:07:05 UTC
Permalink
P.S.
Post by Reinier Post
$stmt->from->join[1]->column = 'salary';
should be

$stmt->from->join[1]->table = 'salary';

Sorry about that.

The idea is to have something like what the CGI module provides for HTML.
--
Reinier
Jens Rehsack
2012-04-08 11:59:27 UTC
Permalink
Post by Jens Rehsack
Post by Jens Rehsack
Greetings,
I am wanting to take a SELECT statement and change the names of the
tables without IMMEDIATELY executing that statement. I was hoping that
SQL::Statement would solve the problem but apparently it can only
EXECUTE a statement. Is this true? I could not find anywhere that
deemed contrary in either the docs nor the source code.
Seems to me that a lot of value is to be found in parsing statements,
changing them and then PRINTING them out or storing them as scalars
for execution at a later time.  Would you be so kind as to provide
this functionality? I honestly do not see any reason why it was not
made available from the first release of this code.
Sorry for the tone, but i was highly disappointed to learn that such a
valuable and simple function was left out during my evaluation of this
software. We will most likely use an alternative, but maybe the next
person will not have to. Thanks in advance.
Hey Jeff,
To your mail itself: I absolutely don't know what you're talking about.
No version information, nothing about the OS/distribution you use.
No test describing what you're doing and what's failing.
Probably you can fix this and after that worry about your tone ;)
Don't worry about it ... i just wanted confirmation that you really
didn't think to have such a valuable feature.
Well, I don't know - because I don't understand what you want.
But a "do what I mean" feature is indeed missing. Patches welcome.
I will "fix this" by simply not using your code. :)
Well, great fix. I'm going to recommend it further.
Impressive things in volunteer projects is that so many people
kindly provide ideas, fixes and improvements.
Thank you very much helping to improve SQL::Statement,
Jens
So since you would like for me to help improve this module then perhaps you
will allow to explain myself one more time
Glad to see it.
(and CC'ed my personal message to the group without my permission).
1st mistake. You gave me the permission to CC dbi-dev@ and/or dbi-users@
or opening a ticket on CPAN containing your message by asking me via e-mail
without having a valid business support contract. Please read SUPPORT
section in S::S for details when you're allowed to mail me private.
http://search.cpan.org/~rehsack/SQL-Statement-1.33/lib/SQL/Statement/Structure.pod#Executing_and_fetching_data_from_SQL_statements
my $cache = {};
my $parser = SQL::Parser->new();
my $stmt = SQL::Statement->new('select foo.name from foo inner join bar on
foo.id=bar.id',$parser);
$stmt->execute( $cache );
my $sql = $stmt->get_sql;
my $date = '20120307' # today's date
# now set the tables
# and get the new sql
my $sql = $stmt->get_sql;
is $sql, 'select foo20120307.name from foo20120307 inner join bar20120307 on
foo20120307.id=bar20120307.id', "WIN!";
In other words, i *thought* this module allowed the client to modify the
parsed SQL components and regenerate a new query. I can't imagine why this
module wouldn't provide such from the get-go.
Well, sounds to me that you neither read the module documentation for the
capabilities of SQL::Statement nor (reading your criticism about CC'ing your
mail to the developer list) the support details. You simply assumed that me
as the author of a name matching CPAN module will help you in private
manner without any benefit for anyone except of yourself.

If you're asking kindly on dbi-users@ using your above expectation,
you might get an answer containing modules with appropriate features.
So, in conclusion, sorry that
you didn't understand my original email and thank you for expressing your
anger by copying my message without my permission.
Well, I don't express any anger by copying your mail to a public list,
I followed the usual support workflow for non-commercial request.
Good luck.
Thanks.

Best regards,
Jens
Jeff Anderson
2012-04-08 13:43:13 UTC
Permalink
Like i said, i was mostly curious of the mindset behind this code that go
through the hard work of parsing a SQL statement but not providing the
ability to alter and reuse that statement.

You win the pointless code award. Congrats.
Post by Jens Rehsack
Post by Jens Rehsack
Post by Jens Rehsack
Greetings,
I am wanting to take a SELECT statement and change the names of the
tables without IMMEDIATELY executing that statement. I was hoping
that
Post by Jens Rehsack
Post by Jens Rehsack
SQL::Statement would solve the problem but apparently it can only
EXECUTE a statement. Is this true? I could not find anywhere that
deemed contrary in either the docs nor the source code.
Seems to me that a lot of value is to be found in parsing statements,
changing them and then PRINTING them out or storing them as scalars
for execution at a later time. Would you be so kind as to provide
this functionality? I honestly do not see any reason why it was not
made available from the first release of this code.
Sorry for the tone, but i was highly disappointed to learn that such
a
Post by Jens Rehsack
Post by Jens Rehsack
valuable and simple function was left out during my evaluation of
this
Post by Jens Rehsack
Post by Jens Rehsack
software. We will most likely use an alternative, but maybe the next
person will not have to. Thanks in advance.
Hey Jeff,
To your mail itself: I absolutely don't know what you're talking
about.
Post by Jens Rehsack
Post by Jens Rehsack
No version information, nothing about the OS/distribution you use.
No test describing what you're doing and what's failing.
Probably you can fix this and after that worry about your tone ;)
Don't worry about it ... i just wanted confirmation that you really
didn't think to have such a valuable feature.
Well, I don't know - because I don't understand what you want.
But a "do what I mean" feature is indeed missing. Patches welcome.
I will "fix this" by simply not using your code. :)
Well, great fix. I'm going to recommend it further.
Impressive things in volunteer projects is that so many people
kindly provide ideas, fixes and improvements.
Thank you very much helping to improve SQL::Statement,
Jens
So since you would like for me to help improve this module then perhaps
you
will allow to explain myself one more time
Glad to see it.
(and CC'ed my personal message to the group without my permission).
or opening a ticket on CPAN containing your message by asking me via e-mail
without having a valid business support contract. Please read SUPPORT
section in S::S for details when you're allowed to mail me private.
http://search.cpan.org/~rehsack/SQL-Statement-1.33/lib/SQL/Statement/Structure.pod#Executing_and_fetching_data_from_SQL_statements
There is this bit of code (i changed the SQL statement to fit my
my $cache = {};
my $parser = SQL::Parser->new();
my $stmt = SQL::Statement->new('select foo.name from foo inner join
bar on
foo.id=bar.id',$parser);
$stmt->execute( $cache );
my $sql = $stmt->get_sql;
my $date = '20120307' # today's date
# now set the tables
# and get the new sql
my $sql = $stmt->get_sql;
is $sql, 'select foo20120307.name from foo20120307 inner join
bar20120307 on
foo20120307.id=bar20120307.id', "WIN!";
In other words, i *thought* this module allowed the client to modify the
parsed SQL components and regenerate a new query. I can't imagine why
this
module wouldn't provide such from the get-go.
Well, sounds to me that you neither read the module documentation for the
capabilities of SQL::Statement nor (reading your criticism about CC'ing your
mail to the developer list) the support details. You simply assumed that me
as the author of a name matching CPAN module will help you in private
manner without any benefit for anyone except of yourself.
you might get an answer containing modules with appropriate features.
So, in conclusion, sorry that
you didn't understand my original email and thank you for expressing your
anger by copying my message without my permission.
Well, I don't express any anger by copying your mail to a public list,
I followed the usual support workflow for non-commercial request.
Good luck.
Thanks.
Best regards,
Jens
--
jeffa
Tim Bunce
2012-04-10 08:40:06 UTC
Permalink
Hello Jeff.
Post by Jeff Anderson
Like i said, i was mostly curious of the mindset behind this code that go
through the hard work of parsing a SQL statement but not providing the
ability to alter and reuse that statement.
My answer, for your curiosity, is that no one has needed it enough to put
in the work required to implement it. It's as simple as that.
Post by Jeff Anderson
You win the pointless code award. Congrats.
Thank you, on behalf of Jens and the many other people who have
contributed many hours of their own free time to SQL::Statement over the
last fourteen years[1].

Tim.

[1] https://metacpan.org/module/JWIED/SQL-Statement-0.1001/lib/SQL/Statement.pm
Jens Rehsack
2012-04-10 13:40:12 UTC
Permalink
Post by Tim Bunce
Hello Jeff.
Post by Jeff Anderson
Like i said, i was mostly curious of the mindset behind this code that go
through the hard work of parsing a SQL statement but not providing the
ability to alter and reuse that statement.
My answer, for your curiosity, is that no one has needed it enough to put
in the work required to implement it. It's as simple as that.
Or - what I like to mention - there's missing a European equivalent for
crowd funding.

I always wanted to rewrite SQL::Statement reusing ribasushi's great
SQL::Translator (allows to parse different SQL dialects - and have only
one SQL parser on CPAN to maintain) and simplifying the sql
processing engine using OO techniques, but it took nearly three man
months to update DBD::File and related - it would take much more
time to rework SQL::Statement. This is no quick goal, no low hangin
fruit - so I expect no one will "need it enough". Technicians usually
don't manage so much money, managers don't understand the
benefit.

I expect, more parts of Perl and/or DBI have similar funding problems.

Best regards,
Jens

PS: I deleted Jeff from receiver list because I don't want to repeat
useless discussion.
Tim Bunce
2012-04-10 15:57:04 UTC
Permalink
Post by Jens Rehsack
Or - what I like to mention - there's missing a European equivalent for
crowd funding.
I always wanted to rewrite SQL::Statement reusing ribasushi's great
SQL::Translator (allows to parse different SQL dialects - and have only
one SQL parser on CPAN to maintain) and simplifying the sql
processing engine using OO techniques, but it took nearly three man
months to update DBD::File and related - it would take much more
time to rework SQL::Statement. This is no quick goal, no low hangin
fruit - so I expect no one will "need it enough". Technicians usually
don't manage so much money, managers don't understand the
benefit.
I expect, more parts of Perl and/or DBI have similar funding problems.
Well it just so happens that there's a chunk of money sitting in a
Perl Foundation bucket called the "DBI Development Fund".
Some of you may remember there was a fund raising drive several years ago.

[later] Oh, it was 2004! Those were heady days of DBI v2 and perl v6.
http://groups.google.com/group/perl.dbi.users/msg/caf189d7b404a003?pli=1
Post by Jens Rehsack
From time-to-time I've pondered how the money might best be used.
(I forget how much, a few thousand I think.) I've never drawn any money
from it myself, and I'm not particularly keen to.

So I'm open to ideas for its best use. Some items from the Roadmap (in
the link above) may still be valid and useful. I imagine they'd need to be
approved by the TPF. Obviously, only practical projects with clear goals
would get much consideration.

With regard to migrating SQL::Statement to be built on SQL::Translator,
that's clearly a big task, but one that I presume could be broken down
into smaller tasks.
Post by Jens Rehsack
PS: I deleted Jeff from receiver list because I don't want to repeat
useless discussion.
Yes, let's let it rest.

Tim.
Darren Duncan
2012-04-11 02:58:32 UTC
Permalink
Post by Tim Bunce
With regard to migrating SQL::Statement to be built on SQL::Translator,
that's clearly a big task, but one that I presume could be broken down
into smaller tasks.
I think that it might work better to treat SQL like a general purpose
programming language, as much as is possible, rather than something inordinately
special, and then use that as a starting point from which to design and build a
parser for it.

For example, think of your "create table" et al like a data type definition
(columns are attributes, constraints are constraints, etc) plus variable
declaration, and think of your "select" etc like a value expression, and so on;
stored procedures etc are routine definitions; bind parameters are parameters.

Perhaps something like PPI might be a better starting point (this is a stab in
the dark) as it is designed for a full language.

That's what I would do if I were making a SQL parser. Oh wait, I am!

-- Darren Duncan
Jens Rehsack
2012-04-11 09:12:06 UTC
Permalink
Post by Darren Duncan
Post by Tim Bunce
With regard to migrating SQL::Statement to be built on SQL::Translator,
that's clearly a big task, but one that I presume could be broken down
into smaller tasks.
I think that it might work better to treat SQL like a general purpose
programming language, as much as is possible, rather than something
inordinately special, and then use that as a starting point from which
to design and build a parser for it.
For example, think of your "create table" et al like a data type
definition (columns are attributes, constraints are constraints, etc)
plus variable declaration, and think of your "select" etc like a value
expression, and so on; stored procedures etc are routine definitions;
bind parameters are parameters.
Which would result in another module like current SQL::Parser.
I want (and this is a primary goal of the rewrite target) not a
strong coupled sql parsing engine - I want a intermediate data
structure resulting from parse process which needs to be compiled
into execution commands.

The usage of the command pattern worked very well in where clause
optimization - reduces complexity and improves performance.
That's why I expect more similar improvements when doing it for
the whole SQL::Statement processing engine.
Post by Darren Duncan
Perhaps something like PPI might be a better starting point (this is a
stab in the dark) as it is designed for a full language.
SQL::Translator has (or should have) the infrastructure for this.
Post by Darren Duncan
That's what I would do if I were making a SQL parser. Oh wait, I am!
Just another SQL Parser? Why not taking/improving one of the
existing ones? Or is it, because they're not invented "here"?

/Jens
Darren Duncan
2012-04-11 19:26:48 UTC
Permalink
Post by Jens Rehsack
Post by Darren Duncan
That's what I would do if I were making a SQL parser. Oh wait, I am!
Just another SQL Parser? Why not taking/improving one of the
existing ones? Or is it, because they're not invented "here"?
No, not "just another"; I don't do that kind of thing.

I'm creating a new general purpose but database savvy programming language,
first implemented in Perl 5 but that ultimately would self-host, which one can
either use to write an application in or write a DBMS in. I am also writing a
module in this language which provides all the API and semantics of SQL.
Thereby, one can "write SQL" using either the native syntax of the language,
which looks loosely like Perl, but I would also provide a parser for actual SQL
syntax that maps to the SQL-semantics module, so one can take existing SQL code
and run it in Perl. The initial Perl 5 implementation would implement a DBMS
natively, but subsequently there is the option to farm out to or map to existing
DBMSs, which can be quite direct for code mapped to the SQL-semantics module.

I expect that I will try to utilize existing SQL parsing modules on CPAN for my
project where they are capable enough or are designed in a manner that they can
be made capable enough without a rewrite. My reason to exist isn't SQL parsing
for its own sake, but SQL parsing would support the other things.

Do you know any SQL parsing modules that can actually *run* the SQL in Perl or
that generate Perl code from SQL that does the same thing with Perl data?

-- Darren Duncan

Jens Rehsack
2012-04-11 13:06:36 UTC
Permalink
Post by Tim Bunce
Post by Jens Rehsack
Or - what I like to mention - there's missing a European equivalent for
crowd funding.
I always wanted to rewrite SQL::Statement reusing ribasushi's great
SQL::Translator (allows to parse different SQL dialects - and have only
one SQL parser on CPAN to maintain) and simplifying the sql
processing engine using OO techniques, but it took nearly three man
months to update DBD::File and related - it would take much more
time to rework SQL::Statement. This is no quick goal, no low hangin
fruit - so I expect no one will "need it enough". Technicians usually
don't manage so much money, managers don't understand the
benefit.
I expect, more parts of Perl and/or DBI have similar funding problems.
Well it just so happens that there's a chunk of money sitting in a
Perl Foundation bucket called the "DBI Development Fund".
Some of you may remember there was a fund raising drive several years ago.
[later] Oh, it was 2004! Those were heady days of DBI v2 and perl v6.
http://groups.google.com/group/perl.dbi.users/msg/caf189d7b404a003?pli=1
From time-to-time I've pondered how the money might best be used.
(I forget how much, a few thousand I think.) I've never drawn any money
from it myself, and I'm not particularly keen to.
So I'm open to ideas for its best use. Some items from the Roadmap (in
the link above) may still be valid and useful. I imagine they'd need to be
approved by the TPF. Obviously, only practical projects with clear goals
would get much consideration.
I didn't beg for money in form of payment - even if owning more money
is not worse in general, getting payed is not the problem. The problem
for me as person was - being 3 month at home developing on something
no one of current active developers had understood completely in it's
depth was a lot of digging, asking and waiting actions with less
social interaction usually happens in normal business days.

What I really missed was someone who had some time, too, to talk about.
I'm not sure if this is possible, because I don't know much people
with enough background to help out there (to be true: I can imagine
of 4-6).
Post by Tim Bunce
With regard to migrating SQL::Statement to be built on SQL::Translator,
that's clearly a big task, but one that I presume could be broken down
into smaller tasks.
This is probably a good first start either. When the tasks are know
(which could be fully clarified before any line of code is written),
it's probably much easier to find someone with time who help thinking
and digging ;)

Best regards,
Jens
Jeff Anderson
2012-04-10 12:48:55 UTC
Permalink
Thank you to Jens for expressing his anger by making this public. :)

What a pointless waste on his behalf.
Post by Tim Bunce
Hello Jeff.
Post by Jeff Anderson
Like i said, i was mostly curious of the mindset behind this code that go
through the hard work of parsing a SQL statement but not providing the
ability to alter and reuse that statement.
My answer, for your curiosity, is that no one has needed it enough to put
in the work required to implement it. It's as simple as that.
Post by Jeff Anderson
You win the pointless code award. Congrats.
Thank you, on behalf of Jens and the many other people who have
contributed many hours of their own free time to SQL::Statement over the
last fourteen years[1].
Tim.
[1] https://metacpan.org/module/JWIED/SQL-Statement-0.1001/lib/SQL/Statement.pm
--
jeffa
Jeff Anderson
2012-04-07 17:01:04 UTC
Permalink
So since you would like for me to help improve this module then perhaps you
will allow to explain myself one more time (and CC'ed my personal message
to the group without my permission).

One this here page:
http://search.cpan.org/~rehsack/SQL-Statement-1.33/lib/SQL/Statement/Structure.pod#Executing_and_fetching_data_from_SQL_statements

There is this bit of code (i changed the SQL statement to fit my problem):

my $cache = {};
my $parser = SQL::Parser->new();
my $stmt = SQL::Statement->new('select foo.name from foo inner join bar
on foo.id=bar.id',$parser);
$stmt->execute( $cache );

I would like to do this:

my $sql = $stmt->get_sql;

Because i would like to do this:

my @tables = $stmt->tables();
my $date = '20120307' # today's date
$_ .= $date for @tables;

# now set the tables
$stmt->tables( @tables );

# and get the new sql
my $sql = $stmt->get_sql;

is $sql, 'select foo20120307.name from foo20120307 inner join bar20120307
on foo20120307.id=bar20120307.id', "WIN!";


In other words, i *thought* this module allowed the client to modify the
parsed SQL components and regenerate a new query. I can't imagine why this
module wouldn't provide such from the get-go. So, in conclusion, sorry that
you didn't understand my original email and thank you for expressing your
anger by copying my message without my permission.

Good luck.
Post by Jens Rehsack
Post by Jens Rehsack
Greetings,
I am wanting to take a SELECT statement and change the names of the
tables without IMMEDIATELY executing that statement. I was hoping that
SQL::Statement would solve the problem but apparently it can only
EXECUTE a statement. Is this true? I could not find anywhere that
deemed contrary in either the docs nor the source code.
Seems to me that a lot of value is to be found in parsing statements,
changing them and then PRINTING them out or storing them as scalars
for execution at a later time. Would you be so kind as to provide
this functionality? I honestly do not see any reason why it was not
made available from the first release of this code.
Sorry for the tone, but i was highly disappointed to learn that such a
valuable and simple function was left out during my evaluation of this
software. We will most likely use an alternative, but maybe the next
person will not have to. Thanks in advance.
Hey Jeff,
To your mail itself: I absolutely don't know what you're talking about.
No version information, nothing about the OS/distribution you use.
No test describing what you're doing and what's failing.
Probably you can fix this and after that worry about your tone ;)
Don't worry about it ... i just wanted confirmation that you really
didn't think to have such a valuable feature.
Well, I don't know - because I don't understand what you want.
But a "do what I mean" feature is indeed missing. Patches welcome.
I will "fix this" by simply not using your code. :)
Well, great fix. I'm going to recommend it further.
Impressive things in volunteer projects is that so many people
kindly provide ideas, fixes and improvements.
Thank you very much helping to improve SQL::Statement,
Jens
--
jeffa
Continue reading on narkive:
Loading...