I've selected the half-way.
Here's what I've started:
- its a DB attribute
- the statement handle obtains the value at C<prepare> time from the db
handle
- I'm planning on allowing retrieval of the value in the statement handle,
but not setting it
Jeff
> -----Original Message-----
> From: Tim Bunce [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 06, 2001 9:53 AM
> To: Simon Oliver
> Cc: Jeff Urlwin; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: DBD::ODBC patch for ::->: translation (sapdb triggers)
>
>
> On Thu, Dec 06, 2001 at 08:17:08AM +0000, Simon Oliver wrote:
> > > > Make it a driver-private attribute for now. Maybe
> > > >
> > > > odbc_ignore_named_placeholders => 1
> > > >
> > > > Umm, or maybe something shorter :) Maybe odbc_no_named_ph ?
> > > >
> > > > The new preparse() stuff the DBI will be getting soon will impact
> > > > this kind of thing, so no point adding new DBI attributes just yet.
> > >
> > > Ok. I also, at this point, prefer it to be a database
> option, rather than a
> > > statement option. My thinking is that someone who is going
> to use it will
> > > rather set it and forget it than set it for each new STH.
> Also, C<do> would
> > > inherit it...
> > Why not make it a transparent attribute like many of the "ATTRIBUTES
> > COMMON TO ALL HANDLES":
> >
> > ...."attributes are inherited by child handles. That is, the value of an
> > inherited attribute in a newly created statement handle is the same as
> > the value in the parent database handle. Changes to attributes in the
> > new statement handle do not affect the parent database handle and
> > changes to the database handle do not affect existing statement handles,
> > only future ones."
>
> You could do, but I wouldn't bother. I agree with Jeff that it'll
> tend to be a set-it-and-forget-it option, and the new preparse() stuff
> will change the game anyway. Let's not over-engineer this one right now.
>
> Tim.
>
