From: | Nic Ferrier <nferrier(at)tapsellferrier(dot)co(dot)uk> |
---|---|
To: | Aaron Mulder <ammulder(at)alumni(dot)princeton(dot)edu> |
Cc: | pgsql-jdbc <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Out of memory error on huge resultset |
Date: | 2002-10-12 12:20:49 |
Message-ID: | 877kgnzw4e.fsf@pooh-sticks-bridge.tapsellferrier.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Aaron Mulder <ammulder(at)alumni(dot)princeton(dot)edu> writes:
> On 12 Oct 2002, Nic Ferrier wrote:
> > That's a really good point Barry. I never do that so it's not
> > something I'd considered.
> >
> > Isn't a solution to only do the to_cursor translation when the
> > statement given begins with "SELECT "?
>
> Well, there's always the case of "select * from
> really_small_table; insert into reall_small table; select * from
> really_big_table;..."
>
> In practice, I've used some 100+ statement commands, because we
> run updates to one or our internal databases in DBVisualizer, and it
> passes the entire script as one command. On the other hand, those are all
> updates, but there's nothing preventing you from putting some selects in
> there.
>
> I think it's best to do what Barry mentioned and disable this for
> statements containing a ; (or at least containing a ; with any non
> whitespace thereafter). Then just consider whether you want to search for
> quoted/escaped ;s.
Yes. It's tricky isn't it. Obviously using multiple SQL statements is
kinda popular. I've always used stored procs.
This is certainly more of a can of worms that I first
thought. However, I'll finish it off and we'll see how messy it is
then.
Nic
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2002-10-12 12:27:34 | Re: Out of memory error on huge resultset |
Previous Message | Aaron Mulder | 2002-10-12 12:04:13 | Re: Out of memory error on huge resultset |