On Tue, May 05, 2009 at 01:49:10PM +0200, H.Merijn Brand wrote:
> On Tue, 5 May 2009 12:08:53 +0100, Tim Bunce <[email protected]>
> wrote:
>
> > On Mon, May 04, 2009 at 04:06:47PM +0200, H.Merijn Brand wrote:
> > > I've hit a failure, which I am not about if it is my fault or that I
> > > have to blame something else
> > >
> > > $dbh->do ("drop table $_") for $dbh->tables ();
> > >
> > > Now that DBI returns the tables quoted, I expect that to work.
> > >
> > > DBD::CSV uses the current user name as schema name, so the table list
> > > looks like
> > >
> > > $VAR1 = [
> > > '"merijn".testaa.csv',
> > > '"merijn".testab',
> > > '"merijn".testac',
> > > '"merijn".testad.txt',
> > > '"merijn".testae.csv',
> > > ];
> >
> > [Ignoring the issue you're refering to]
> >
> > Why should DBD::CSV support schemas at all?
>
> Because it was in there from the start. (In fact it was in DBD::File).
> Not that I /like/ it, nor see the use of it, but the default
> schema-name for DBD-File is the owner of the folder in which the
> datafile resides
That seems wrong. Schemas primarily provide namespaces. The association
with username is mostly an accident of history.
> > What value does that give?
>
> beats me, but I'm sure I break things if I simply remove it
>
> > What use-cases does it help?
>
> I have just implemented f_schema in DBD::File, so I can disable the
> darn thing with { f_schema => undef }
Ah, ok. That's a good thing :)
> > What are the semantics of 'schemas' in DBD::CSV?
>
> none that I am aware of
There must be some...
1. when reading metadata, the default schema-name is the owner of the
folder in which the datafile resides
2. when refering to a table name in an SQL statement
the schema portion is... ignored?
Tim.
p.s. You've missed DBI 1.608 but hopefully the gap before 1.609 won't be
as large.
