On Wed, Nov 20, 2002 at 01:51:12PM +0100, H.Merijn Brand wrote:
> On Wed 20 Nov 2002 11:49, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 19, 2002 at 03:13:54PM -0800, David Wheeler wrote:
> > >
> > > * What are the guidelines for handling trace? I note that DBD::Pg
> > > checks dbis->debug far more often than, say, DBD::mysql, and generally
> > > sets a lower threshold (1). What sorts of things should a driver be
> > > printing at what debug/trace levels?
> >
> > Drivers should rarely if ever print anything below trace level 3.
> > Quite a few drivers get this wrong and it can be quite annoying to
> > the users to have to wade through lots of driver output when all
> > they want is the basic DBI level 1 or 2 trace. Use levels around
> > 4 through 7 to add more (obscure) detail.
>
> I've added a driver specific verbose setting to be able to see driver specific
> debugging. IIRC, Tim didn't agree with the name, so I have to change it
> sometime, but - certainly in the development phase - it might be very handy to
> skip the DBI debug, and only see the driver specific dubugging
>
> my $dbh = DBI->connect (....);
> $dbh->{DBDverbose} = 9;
>
> is what I have currently implemented in DBD::Unify
> where the highest of this internal verbosity level or DBI's trace level is
> used for reporting. Again, this internal level is probably only usefule for
> people that are conbcerned with the specific DBD implementation (like you are),
> and not the end user.
And all driver-specific attribute should being with the driver-specific
prefix, 'pg_' in the case of Postgres.
I have vague ideas about using the high-bits of the trace level to
enable tracing of specific topics, one day.
> > > I notice that
> > > DBD::ODBC, for example, doesn't appear to do anything special with
> > > regard to comments. And if comments *are* supported by DBI, and DBD::Pg
> > > is doing the right thing by watching out for them, wouldn't it be
> > > smarter for DBD::Pg to cut them *out* of its internal copy of the SQL
> > > statement so that dbd_st_execute() doesn't also have to deal with them?
> >
> > Why should dbd_st_execute have to "deal" with them? The whole string
> > should just be sent off to the server.
>
> Because some database interfaces need to pass storage space along with the
> retreival statement, so you need to know how many input and output variables
> are expected before you pass it.
Umm, sure, but that last question I was replying to related to
stripping out comments, not counting input and output variables.
Tim.
