AW: AW: [HACKERS] Another nasty cache problem - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: AW: [HACKERS] Another nasty cache problem
Date
Msg-id 219F68D65015D011A8E000006F8590C603FDC243@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-hackers
> Zeugswetter Andreas SB wrote:
> > 
> > > Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> > > > What about portals? Doesn't psql use portals?
> > >
> > > No ... portals are a backend concept ...
> > >
> > 
> > I think the previous frontend "monitor" did use a portal for the
> > selects. The so called "blank portal".
> > 
> > I don't really see any advantage, that psql does not do a fetch loop
> > with a portal.
> > Is it possible in psql do do any "fetch" stuff, after doing a
> > select * from table ?
> 
> Yes it is if you set up a cursor. 

My question implied, that a cursor was not set up. That is
type: select * from tab; in psql.

> I think Tom was right that psql
> shouldn't use a portal just as a matter of course, because things
> work differently in that case (locks?).

There is no difference in locking behavior.
So the question remains, why don't we always use a cursor in psql.
It seems the current behavior wastes resources without an obvious
advantage.

Andreas


pgsql-hackers by date:

Previous
From: Horák Daniel
Date:
Subject: Small update for WinNT port
Next
From: Vince Daniels
Date:
Subject: Re: Postgresql Perl Problem