| From: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
|---|---|
| To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
| Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'chris(at)bitmead(dot)com'" <chris(at)bitmead(dot)com>, "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: AW: [HACKERS] Another nasty cache problem |
| Date: | 2000-02-08 22:41:17 |
| Message-ID: | 38A09B8D.C8AA7C7B@nimrod.itg.telecom.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Zeugswetter Andreas SB wrote:
>
> > Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)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. 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?). I'm sure it could be a
useful option though.
>
> The result is fed to a pager anyway.
>
> Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Bitmead | 2000-02-08 22:50:03 | Re: [HACKERS] Ordering of pg_dump output |
| Previous Message | Jan Wieck | 2000-02-08 19:45:37 | Re: [HACKERS] Deferred trigger queue |