Hi,
it was silent around SQL::Statement for a long time ...
I uploaded a new release fixing some open bugs this morning. Special thanks is
going out to Slaven Rezic for supporting by running tests.
Changes log for Perl extension SQL::Statement
1.407 2015-05-26
* Release 1.406_002 without
Hi,
I recently uploaded a dev-release of SQL-Statement (1.406_001) because of so
many (partially exciting patches from community).
I hereby kindly ask anybody who's using it to test it whether it works as
expected or not.
I'm looking forward to release 1.407 at begin of next we
Am 05.02.2015 um 18:14 schrieb Peter Rabbitson :
> On 02/05/2015 06:11 PM, Jens Rehsack wrote:
>> Hi Michael,
>>
>> I think I will do. Math::Base::Convert with convert for up-to-base64
>> seems to be fine
>
> I still think providing an arbitrary "up to base64" conversion is a mistake.
> Consid
On 02/05/2015 06:11 PM, Jens Rehsack wrote:
Hi Michael,
I think I will do. Math::Base::Convert with convert for up-to-base64
seems to be fine
I still think providing an arbitrary "up to base64" conversion is a
mistake. Consider the standardized base32 alphabet:
http://en.wikipedia.org/wiki/B
he CONV function itself wasn't based on SQL-92, but since functions
>> like HEX/BIN/OCT were already needed, I wrote it for those. The name
>> was based on the MySQL function.
>>
>> On Mon, Dec 15, 2014 at 4:40 AM, Jens Rehsack
>> wrote:
>>
>>>
hose. The name was based
on the MySQL function.
On Mon, Dec 15, 2014 at 4:40 AM, Jens Rehsack wrote:
> Hi,
>
> during review of SQL::Statement wrt. RT#100551 I realized that the
> introduced SQL_FUNCTION_CONV (
> https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/Sta
sponses I speak only for myself. I have no idea what other people might need.
- Original Message -
> Hi,
>
> during review of SQL::Statement wrt. RT#100551 I realized that the introduced
> SQL_FUNCTION_CONV
> (https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/Sta
Am 15.12.2014 um 10:54 schrieb Darren Duncan :
> On 2014-12-15 1:40 AM, Jens Rehsack wrote:
>> during review of SQL::Statement wrt. RT#100551 I realized that the
>> introduced SQL_FUNCTION_CONV
>> (https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/Statem
On 2014-12-15 1:40 AM, Jens Rehsack wrote:
during review of SQL::Statement wrt. RT#100551 I realized that the introduced
SQL_FUNCTION_CONV
(https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/Statement/Functions.pm#L454)
is unnecessary over-complex.
Funny, when I first saw that
Hi,
during review of SQL::Statement wrt. RT#100551 I realized that the introduced
SQL_FUNCTION_CONV
(https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/Statement/Functions.pm#L454)
is unnecessary over-complex.
Since I learned that silent removal of once shipped functionality is a
Jens,
Actually, the documentation says:
"SQL::Statement is the basis for at least eight existing DBDs (DBI database
drivers). If you have a new data source, you too can create a DBD without
having to reinvent the SQL wheel. It is fun and easy so become a DBD author
today!"
This part
/search.cpan.org/~rehsack/SQL-Statement-1.405/lib/SQL/Statement/Embed.pod
> but they don't work. The DBD::Foo example gives the following error message:
>
> --- snip ---
> wit:bin sauber$ perl -I../lib dbdfoo.pl
> Use of uninitialized value $drv_prefix in concatenation (.) o
paths:
M .gitignore
Log Message:
---
merge *.bak pattern from SQL::Statement
On Fri, 19 Apr 2013 11:05:06 +0200, Jens Rehsack
wrote:
> On 18.04.13 17:17, H.Merijn Brand wrote:
> > On request from Jens:
> >
> > $ git clone github.com:perl5-dbi/dbi.git SQL-Statement
> >
> > is now a full copy of https://github.com/rehsack/SQL-Statemen
On 18.04.13 17:17, H.Merijn Brand wrote:
On request from Jens:
$ git clone github.com:perl5-dbi/dbi.git SQL-Statement
is now a full copy of https://github.com/rehsack/SQL-Statement
$ pwd
/tmp/SQL-Statement
$ git push --tags
Everything up-to-date
$ git branch -a
* master
remotes/origin
On request from Jens:
$ git clone github.com:perl5-dbi/dbi.git SQL-Statement
is now a full copy of https://github.com/rehsack/SQL-Statement
The new location does NOT know about the old, as it can now be
used as the new decisive source: that is up to Jens.
Enjoy!
--
H.Merijn Brand http
Hi,
SQL::Statement 1.402 has been uploaded to PAUSE and should be updated
where ever possible.
Version 1.402, released December 19, 2012
-
[Misc]
* add Math::Complex 1.56 as recommendation (RT#81926, Sam Ferencik)
* add Math::BigInt 1.88 as
Hi,
hereby I announce the SQL::Statement 1.401 release containing following
changes:
Version 1.401, released October 29, 2012
-
[Misc]
* Switch to 3-digited minor version
[Bug fixes]
* undo literal replaces in subqueries before passing them to
Hi,
if anyone waits for next SQL::Statement release, feel invited to test
and review latest development snapshot.
Few patches for broken Perl versions are missing until I think it's
ready for being released.
/Jens
Hi all,
inspired by the work on new streaming feature of DBD::File I uploaded a
new developer release of SQL::Statement to get new drive into the pure
perl DBD's ...
Hope I get feedback to release new full working release soon.
/Jens
Original Message
Subject: CPAN Uplo
Jens Rehsack wrote:
Am 11.04.2012 04:58, schrieb 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
Am 10.04.2012 17:57, schrieb Tim Bunce:
> On Tue, Apr 10, 2012 at 03:40:12PM +0200, Jens Rehsack wrote:
>>
>> Or - what I like to mention - there's missing a European equivalent for
>> crowd funding.
>>
>> I always wanted to rewrite SQL::Statement reusin
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&#
Am 11.04.2012 04:58, schrieb Darren Duncan:
> Tim Bunce wrote:
>> 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
Tim Bunce wrote:
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
On Tue, Apr 10, 2012 at 03:40:12PM +0200, Jens Rehsack wrote:
>
> 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 diffe
Am 10. April 2012 10:40 schrieb Tim Bunce :
> Hello Jeff.
>
> On Sun, Apr 08, 2012 at 06:43:13AM -0700, Jeff Anderson wrote:
>> 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 th
Hello Jeff.
On Sun, Apr 08, 2012 at 06:43:13AM -0700, Jeff Anderson wrote:
> 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,
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.
On Sun, Apr 8, 2012 at 4:59 AM, Jens Rehsack wrote:
> A
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/Structur
derson :
>>>>> 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 probl
P.S.
> $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
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
gt; 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.
>
On Sat, 7 Apr 2012 08:30:27 +0100, Jens Rehsack
wrote:
> Am 7. April 2012 01:30 schrieb Jeff Anderson :
> > Greetings,
> >
> > I am wanting to take a SELECT statement and change the names of the
> > tables without IMMEDIATELY executing that statement. I was hoping th
Am 7. April 2012 01:30 schrieb Jeff Anderson :
> 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
> EXECU
On Wed, Feb 29, 2012 at 10:49:09AM +, Martin J. Evans wrote:
> On 26/02/12 12:27, Tim Bunce wrote:
> >On Sat, Feb 25, 2012 at 02:18:56PM -0800, Jonathan Leffler wrote:
> >
> >>I'm slightly puzzled by a couple of the tests skipping because 'Not
>
uzzled by a couple of the tests skipping because 'Not running
with SQL::Statement', when
in fact I have SQL::Statement installed.
t/52dbm_complex.t ... ok
t/zvg_52dbm_complex.t ... ok
t/zvn_52dbm_complex.t ... skipped: Not running with
tests skipping because 'Not
> running with SQL::Statement', when
>in fact I have SQL::Statement installed.
>
>t/52dbm_complex.t ... ok
>t/zvg_52dbm_complex.t ... ok
>t/zvn_52dbm_complex.t ... skipped: Not running with SQL::
), but there seems to a lack of uniformity
> > with it all. I'm not really blaming anybody for that, but it's just has
> > ended up that way. Four different subclasses overloads from three
> different
> > CPAN packages seem to link together the "abstract DBD obj
examples only (remember: free time project - not got paid for it).
> Plus, I'm still not getting where this is supposed to start.
> DBD::Sys::Plugin's POD is barely a page, and most of the example plugins
> almost look too simple.
They are! There is no rocket science.
&
On Thu, Dec 1, 2011 at 1:27 AM, Jens Rehsack wrote:
> > On Wed, Nov 30, 2011 at 4:14 AM, Jens Rehsack
> > wrote:
>
> > But, we still need an outlet to put these things in. I keep hearing
> about a
> I see no reason to do this _now_. Nothing you desire needs S::S changes,
> only the way you de
gt; > different cased files to have the same table key and screwing stuff up
>> > with
>> > JOIN. (Yeah, it's rare for somebody to actually be using both "FOOBAR"
>> > and
>> > "foobar" in the same query...)
>>
>> I hope t
2011/11/29 Brendan Byrd :
> Found a potential bug, but it looks deliberate, so I wanted to see why it
> was coded that way. In SQL::Statement, open_tables is using $self->tables()
> for mostly everything, which will contain the correct case for all of the
> table names. (IE: FOOB
Found a potential bug, but it looks deliberate, so I wanted to see why it
was coded that way. In SQL::Statement, open_tables is using
$self->tables() for mostly everything, which will contain the correct case
for all of the table names. (IE: FOOBAR = foobar and "FOOBAR" = FOOBAR)
ma' or something
like that.
When you write a Pure-Perl DBD using SQL::Statement, you're well
advised to derive from DBI::DBD::SqlEngine (unless you need to deal
with files, then derive from DBD::File).
And DBI::DBD::SqlEngine falls back to DBI::SQL::Nano in case
no suitable SQL::Statement h
t the table ever
had a schema. This would be a flag called 'dont_strip_schema' or something
like that.
When you write a Pure-Perl DBD using SQL::Statement, you're well
> advised to derive from DBI::DBD::SqlEngine (unless you need to deal
> with files, then derive from DBD::
MP right now, and I'm currently fighting with
>> > SQL::Statement to allow for schema.table formats. The idea would that it
>> > would be possible to reference the MIB name within the table, like
>> > IF_MIB.ifTable for IF-MIB::ifTable. However, I'm finding all kinds of
On Wed, Nov 23, 2011 at 09:34:06AM +0100, Jens Rehsack wrote:
> 2011/11/22 Brendan Byrd :
> > (Adding dbi-dev to conversation for
> > https://rt.cpan.org/Ticket/Display.html?id=72588)
> >
> > Still debugging DBD::SNMP right now, and I'm currently fighting with
> On Wed, Nov 23, 2011 at 3:34 AM, Jens Rehsack
> wrote:
>>
>> 2011/11/22 Brendan Byrd :
>> > (Adding dbi-dev to conversation for
>> > https://rt.cpan.org/Ticket/Display.html?id=72588)
>> >
>> > Still debugging DBD::SNMP right now, and I'
gt; (Adding dbi-dev to conversation for
> > https://rt.cpan.org/Ticket/Display.html?id=72588)
> >
> > Still debugging DBD::SNMP right now, and I'm currently fighting with
> > SQL::Statement to allow for schema.table formats. The idea would that it
> > would be pos
2011/11/22 Brendan Byrd :
> (Adding dbi-dev to conversation for
> https://rt.cpan.org/Ticket/Display.html?id=72588)
>
> Still debugging DBD::SNMP right now, and I'm currently fighting with
> SQL::Statement to allow for schema.table formats. The idea would that it
> would b
(Adding dbi-dev to conversation for
https://rt.cpan.org/Ticket/Display.html?id=72588)
Still debugging DBD::SNMP right now, and I'm currently fighting with
SQL::Statement to allow for schema.table formats. The idea would that it
would be possible to reference the MIB name within the table,
Hi Merijn,
'cause I don't have IRC at $work, we better discuss it on ML (when I'm
able to answer in IRC, you're usually not online anymore (or not yet,
respectively)).
[Sno], SQL::Statement should not mention DBD::CSV in it's requirements
it now causes an endless loop
On 2011.1.6 10:08 PM, Jens Rehsack wrote:
> That's only one step - I want the line numbers of the test, and the test is
> currently written as an hash-entry in a test-list.
By "test" do you mean "where the entry is defined in the hash"? Like, for
example...
#line 1
my %tests = (
aspell.nl.prepl
/home/merijn/.aspell.en.prepl /home/merijn/.aspell.nl.pws
It is a list of words that are not in default dictionaries, but are
correct in the current documentation. Actually, it is now out-of-date
SS-svn > pod-spell-check --aspell
ok 1 - lib/SQL/Dialects/ANSI.pm
ok 2 -
On 01/01/11 07:55, Michael G Schwern wrote:
On 2011.1.1 12:38 AM, Jens Rehsack wrote:
Further I need some help on test rewrite (that's why you, Michael
Schwern, are on CC).
I'd like to rewrite step by step all tests like I did in t/06virtual.t
and t/08join.t. For this I
have to move the test mai
On 2011.1.1 12:38 AM, Jens Rehsack wrote:
> Further I need some help on test rewrite (that's why you, Michael
> Schwern, are on CC).
> I'd like to rewrite step by step all tests like I did in t/06virtual.t
> and t/08join.t. For this I
> have to move the test main loop into the TestLib.pm and I woul
Hi all,
although unfinished test modules rewrite, I decided to publish the
current state of the work
of SQL::Statement fixes and test rewrite in a development release to
collect some feedback.
I expect the full test rewrite will occupy my time for several weeks
and I do not expect a
release
Hi Tim,
regarding to our short discussion in #dbi about the future of SQL::Statement
and the implications to DBI::SQL::Nano here the open discussion for all.
I've want to improve SQL::Statement by design, that means I want to design
it from the basics using Design Patterns (especiall
Hi all,
I'm proud to announce SQL::Statement 1.28. It's the first release for
me where other DBI developers (Matin Evans, H. Merijn Brand) actively
contributed patches and do their own commits.
Thanks for that!
To all users of SQL::Statement or Meta-DBD's: Please take care wh
It would be nice to also get coverage of the nano + DBI::PurePerl case.
Tim.
On Fri, May 07, 2010 at 02:18:46PM +0200, Jens Rehsack wrote:
> Hi,
>
> as requested, I'd like to allow tests against SQL::Statement for those
> DBD's which support it, too.
> If no one ha
Hi,
as requested, I'd like to allow tests against SQL::Statement for those
DBD's which support it, too.
If no one has objections, I'd like to commit attached patch.
Best regards,
Jens
DBI-test-SS.patch
Description: Binary data
I've just uploaded a new release of SQL::Statement which fixes one issue
with Test::Datebase and DBD::DBM reported by Barbie from Birmingham.pm.
The list of changes is small, but I decided to release early (and likely
more often) instead of one big release when all DBD::DBM issues are s
Hi all,
even if wasn't here for a long time (Merijn finally kicked my ass on this
list), I uploaded the (from my point of view) latest development version of
1.21 for SQL::Statement.
I know there're some changes in it, which may break existing code - but I
don't know which code is
On May 12, 2009, at 23:17 , H.Merijn Brand wrote:
On Tue, 12 May 2009 22:12:44 +0200, Gisle Aas
wrote:
I get test failures from SQL-Statement after upgrading to DBI-1.608.
The test pass fine with DBI-1.607. Any ideas?
Yes. That is my (fault) doing (changes in DBD::File)
SQL::Statement
On Tue, 12 May 2009 22:12:44 +0200, Gisle Aas
wrote:
> I get test failures from SQL-Statement after upgrading to DBI-1.608.
> The test pass fine with DBI-1.607. Any ideas?
Yes. That is my (fault) doing (changes in DBD::File)
SQL::Statement is in the scaffolding, and is expected
I get test failures from SQL-Statement after upgrading to DBI-1.608.
The test pass fine with DBI-1.607. Any ideas?
$ perl -Ilib t/05create.t
1..5
SQL::Statement v.1.15
DBD::File::db do failed: You passed 1 parameters where 0 required
[for Statement "CREATE TEMP TABLE aoa AS I
jeff wrote:
Hi friends in the DBI community,
After many years of maintaining SQL::Statement and various pure-Perl
DBDs (RAM, AnyData, File, CSV) I've now finally admitted that I am far
too busy to do an adequate job with the modules. Although I'll stay on
as co-maintainer and hel
e:
> > > > Hi friends in the DBI community,
> > > >
> > > > After many years of maintaining SQL::Statement and various pure-Perl
> > > > DBDs
> > > > (RAM, AnyData, File, CSV) I've now finally admitted that I am far too
> >
On Sun, 19 Apr 2009 21:00:39 +0100, Tim Bunce
wrote:
> On Sat, Apr 18, 2009 at 10:28:02PM +0100, Tim Bunce wrote:
> > On Fri, Apr 17, 2009 at 01:22:42PM -0700, Jeff Zucker wrote:
> > > Hi friends in the DBI community,
> > >
> > > After many years of maintai
On Sat, Apr 18, 2009 at 10:28:02PM +0100, Tim Bunce wrote:
> On Fri, Apr 17, 2009 at 01:22:42PM -0700, Jeff Zucker wrote:
> > Hi friends in the DBI community,
> >
> > After many years of maintaining SQL::Statement and various pure-Perl DBDs
> > (RAM, AnyData, File, CSV
On Fri, Apr 17, 2009 at 01:22:42PM -0700, Jeff Zucker wrote:
> Hi friends in the DBI community,
>
> After many years of maintaining SQL::Statement and various pure-Perl DBDs
> (RAM, AnyData, File, CSV) I've now finally admitted that I am far too busy
> to do an adequate
Hi friends in the DBI community,
After many years of maintaining SQL::Statement and various pure-Perl
DBDs (RAM, AnyData, File, CSV) I've now finally admitted that I am far
too busy to do an adequate job with the modules. Although I'll stay on
as co-maintainer and help out when
hing odd about the svn since the tar.gz appears normal. I've
> uploaded to
>
> http://www.vpservices.com/jeff/programs/SQL-Statement-1.14.tar.gz
>
> I believe this one should untar ok and should pass all tests.
It does. Great job.
HP-UX 11.00/64, perl-5.8.5-d
ed to be
> >a double gzipped file
> >
> Hmm, odd, it's the result of "make dist" and "svn commit". Must be
> something odd about the svn since the tar.gz appears normal. I've
> uploaded to
>
> http://www.vpservices.com/jeff/programs/S
t;svn commit". Must be
> > something odd about the svn since the tar.gz appears normal. I've
> > uploaded to
> >
> > http://www.vpservices.com/jeff/programs/SQL-Statement-1.14.tar.gz
> >
> > I believe this one should untar ok and should pass all tests.
Jonathan Leffler wrote:
the file seemed to be
a double gzipped file
Hmm, odd, it's the result of "make dist" and "svn commit". Must be
something odd about the svn since the tar.gz appears normal. I've
uploaded to
http://www.vpservices.com/jeff/programs/SQL-Statem
rage) and apparently forgot to wrap some of the requires in evals.
> SQL::Statement has no prerequisites but since its most common use is
> with DBI some of the tests do "eval{require DBI; require DBD::File}".
> I've fixed the requires so that some of the tests will be skip
Jeff Zucker wrote:
H.Merijn Brand wrote:
Failed 2/15 test scripts, 86.67% okay. 1/227 subtests failed, 99.56%
okay.
I added over 140 tests in recent releases (and doubled the Devel::Cover
coverage) and apparently forgot to wrap some of the requires in evals.
SQL::Statement has no prerequisites
At 8:37 PM -0700 4/21/05, Jeff Zucker wrote:
I'd much appreciate if those who experienced test failures could try
again with
http://svn.perl.org/modules/SQL-Statement/trunk/SQL-Statement-1.14.tar.gz
Thanks!
I tried 2 different Perl installs, both under the same Mac OS X 10.3.8.
The system
On MacOS X 10.3.9, Perl 5.8.6, I found that (a) the file seemed to be
a double gzipped file (gunzip of the file produced a 'tar' file that
was itself extractable with 'tar -xzf ...', and (b) I still get some
test errors:
...
Manifying blib/man3/SQL::Statement::Structure.3
Man
H.Merijn Brand wrote:
Failed 2/15 test scripts, 86.67% okay. 1/227 subtests failed, 99.56% okay.
I added over 140 tests in recent releases (and doubled the Devel::Cover
coverage) and apparently forgot to wrap some of the requires in evals.
SQL::Statement has no prerequisites but since its most
As I mentioned on dbi-users, I noticed this problem at home, as did
another poster, as did the CPAN testers.
It seems that SQL-Statement 1.12 and 1.13 has a circular dependency
on DBD-AnyData; that is, X's test suite requires Y, and Y's test
suite requires X.
Even when I manually
XBase installed
t/06groupok
t/07case.Can't locate DBD/AnyData.pm in @INC (@INC contains: /
pro/3g l/CPAN/SQL-Statement-1.13/blib/lib /pro/3gl/CPAN/SQL-Statement-1.13/
blib/arch /p ro/lib/perl5/5.8.5/PA-RISC2.0 /pro/lib/perl5/5.8.5 /pro/lib/
perl5/site_perl/5.8. 5/PA-RI
[cc to dbi-dev but please reply to dbi-users or to me]
I'm making available a pre-release version of SQL::Statement with many
new features including vastly improved parens parsing (thanks Dean
Arnold), column aliases (thanks Robert Rothenberg), new built-in
functions including SOUNDER(
[Copied to dbi-dev, but please reply to dbi-users]
Since the cat is out of the bag on upcoming SQL::Statement changes,
here's a preview. Comments on the proposed syntax will be much appreciated.
The major additions will be column name aliases (thanks Robert
Rothenberg), improved pa
I've set my Reply-to to just [EMAIL PROTECTED] as I'm not fond of
cross-posting between the two lists. So could people reply just to
[EMAIL PROTECTED] please. Thanks.
On Wed, Jun 04, 2003 at 09:15:28AM -0700, Jeff Zucker wrote:
> I will be releasing a significantly upgraded SQL::
1) How many joins per stmt allowed ?
2) outer join support ?
3) re: performance: have you considered collecting COUNT(*) from each
datasource
(where available), and then shipping the data from the smaller resultset
directly
to the datasource with the larger resultset ? (not certain how feasible t
I will be releasing a significantly upgraded SQL::Statement and
DBD::File shortly and I have some questions about interface. I'd really
appreciate some feedback. These are the features that are near
finalization:
* heterogeneous SQL across multiple DBI sources
* per-table DBI connec
I have uploaded the latest vesion of SQL-Statement to CPAN. All users
of SQL-Statement, SQL-Parser, DBD::CSV, DBD::AnyData, DBD::Excel and
other modules using SQL::Statement are encouraged to upload the file from:
http://www.cpan.org/modules/by-authors/id/J/JZ/JZUCKER/SQL-Statement-1.005.tar.gz
On Mon, Jan 21, 2002 at 08:36:38AM +0100, Wiedmann, Jochen wrote:
>
> > In the first case SQL::Parser has to know how to parse a statement SQL
> > containing a blob and in the second case it can just allow
> > SQL::Statement to insert the blob without having to par
> In the first case SQL::Parser has to know how to parse a statement SQL
> containing a blob and in the second case it can just allow
> SQL::Statement to insert the blob without having to parse it
> within the
> context of the SQL statement.
Well, of course it is only valid
"Wiedmann, Jochen" wrote:
>
> Hi, Jeff,
>
> > 1. The new SQL::Statement will allow manipulation of blobs, but only
> > with placeholders:
> >
> > This only works in the XS version of SQL::Statement:
> >
> >$dbh->do("
Hi, Jeff,
> 1. The new SQL::Statement will allow manipulation of blobs, but only
> with placeholders:
>
> This only works in the XS version of SQL::Statement:
>
>$dbh->do("INSERT INTO foo VALUES( $blob )");
>
> But this works in both ve
I am fixing some glitches involved in running the t/*.t tests for
DBD::CSV with the new SQL::Statement and have reduced things to two
differences between the old and new Statement and am not sure how to
proceed.
1. The new SQL::Statement will allow manipulation of blobs, but only
with
Tim Bunce wrote:
>
> > * supports case-folding in ORDER BY
>
> Not by default I hope!
No, it's not the default. The default behaviour in all things is the
current behaviour of Jochen's module. Where things like this are
introduced they are done in a way that a subclasser can choose whether
or
On Thu, Aug 23, 2001 at 07:37:06PM -0700, Jeff Zucker wrote:
> I'm pleased to announce the first alpha version of
> SQL::Statement-0.2001. This is a pure perl module based on Jochen
> Wiedmann's SQL::Statement-0.1x series of XS and perl modules.
Great.
> * supports ca
I'm pleased to announce the first alpha version of
SQL::Statement-0.2001. This is a pure perl module based on Jochen
Wiedmann's SQL::Statement-0.1x series of XS and perl modules.
When used with the current version of DBD::CSV or other modules based on
SQL::Statement-0.1x it should b
ff> let the tables close with $dbh->disconnect and/or $dbh going out of
Jeff> scope, and b) should I support both methods of opening/closing styles to
Jeff> support other subclasses of SQL::Statement that want to stick with the
Jeff> old style?
I do think it's a good idea to try a
1 - 100 of 104 matches
Mail list logo
