On Fri, Jul 09, 2004 at 08:08:37AM +0200, Michael Peppler wrote:
> On Thu, 2004-07-08 at 21:42, Andrew Pimlott wrote:
>
> > - Have the database drivers set the close-on-exec flag of the fd used to
> > connect to the database. This makes sense to me, because after an
&g
On Fri, Jul 09, 2004 at 10:58:54AM +0100, Tim Bunce wrote:
> perl5-porters, any thoughts on this?
>
> Any fix needs to be within the debugger. Making the debugger close
> all handles that weren't open when the process started seems 'most
> correct' as it would make the 'restarted' execution closer
I often use the 'R' command of the perl debugger in order to restart my
program. This works by re-exec-ing the debugger. The problem is that
any database connections I have open remain open, keeping transactions
alive, and thus blocking subsequent activity. I observe this problem
with DBD::Pg an
On Tue, Feb 24, 2004 at 09:10:57PM -0500, Rudy Lippan wrote:
> Somewhat old, but:
>
> http://archives.postgresql.org/pgsql-general/2000-02/msg00376.php
The postgres guys sometimes seem to have a weird idea of what
application developers want. "Very minor programming shortcut" indeed!
It would be
On Wed, Feb 25, 2004 at 12:35:07AM +, Tim Bunce wrote:
> On Tue, Feb 24, 2004 at 03:25:09PM -0500, Andrew Pimlott wrote:
> > I am using DBD::Pg, and I noticed that after a statement causes an
> > error, subsequent statements (until rollback) fail with "current
> &
On Tue, Feb 24, 2004 at 03:53:30PM -0500, Jeff Urlwin wrote:
> >
> > I am using DBD::Pg, and I noticed that after a statement
> > causes an error, subsequent statements (until rollback) fail
> > with "current transaction is aborted, queries ignored until
> > end of transaction".
>
> I'm probab
I am using DBD::Pg, and I noticed that after a statement causes an
error, subsequent statements (until rollback) fail with "current
transaction is aborted, queries ignored until end of transaction". I
found some postgres documentation[1] suggesting that it is impossible to
continue after an error.
On Mon, Feb 16, 2004 at 07:46:49PM -0600, Jay Hannah wrote:
> I shouldn't need the warning, especially when it's
> wrong. Even so, it has been useful to me on many occasions in
> dialogues like this:
Well, as I have thought about it more, I agree that there is some
tension between the system warni
On Mon, Feb 16, 2004 at 03:46:28PM -0600, Jay Hannah wrote:
> I would *love* to set another flag/whatever so DBI would bark at us
> whenever $dbh's were garbage collected. Then we'd explicitly know to
> slap ourselves for writing sloppy code... With the warning gone I fear
> we won't know we're bei
On Sat, Feb 14, 2004 at 12:39:29AM +, Tim Bunce wrote:
> Here's what I've added to DBI 1.41:
>
> =item C (boolean)
>
> The C attribute is true if the handle object has been "executed".
This looks perfect, thanks!
Andrew
On Wed, Feb 11, 2004 at 11:43:49AM -0600, Jeff Holt wrote:
> It's an excellent idea for the DBI to fake certain things when it makes
> sense. But transaction control is not one of them. Transaction control
> is appropriately handled only by an application. In other words, only an
> application know
On Wed, Feb 11, 2004 at 04:24:31PM +, Tim Bunce wrote:
> On Wed, Feb 11, 2004 at 08:15:12AM -0500, Andrew Pimlott wrote:
> > Ok, so you'd like to issue the warning in the dangerous case only, but
> > DBI doesn't have the necessary information. That seems like a rathe
On Wed, Feb 11, 2004 at 09:35:59AM +, Tim Bunce wrote:
> For mod_perl you can register a suitable callback.
I am using mod_perl, and that's what I mean about having to jump through
hooks (probably not that difficult in this case) to suppress the
warning.
> The warning as it's a significant sa
This sounds like it must be a FAQ, but I can't find it...
Is there any way to prevent the following from warning "Issuing
rollback() for database handle being DESTROY'd without explicit
disconnect()."?
use DBI;
my $dbh = DBI->connect('dbi:Pg:dbname=...', undef, undef,
14 matches
Mail list logo
