Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] Provide rowcount for utility SELECTs

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>,Hans-Juergen Schoenig <hs(at)cybertec(dot)at>,Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Provide rowcount for utility SELECTs
Date: 2010-02-11 20:00:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>> Robert Haas írta:
>>> ...
>>> OK, please change it.
>> New patch is attached with the discussed changes.
> This looks all wrong.  PORTAL_ONE_SELECT is now being passed through
> FillPortalStore,

Where do you read that? The code in my patch reads:

                                 * If we have not yet run the command,
do so, storing its
!                                * results in the portal's tuplestore.
Do this only for the
!                                * PORTAL_ONE_RETURNING and
!                               if ((portal->strategy !=
PORTAL_ONE_SELECT) && (!portal->holdStore))
                                        FillPortalStore(portal, isTopLevel);

So, PORTAL_ONE_SELECT doesn't run through FillPortalStore().

>  which runs it to completion, whereas it was previously
> passed via PortalRunSelect first, which has different semantics
> regarding the "count" arg.
> Also, even if that weren't wrong, FillPortalStore states at its header
> comment that it is only used for the other two cases (ONE_RETURNING and
> UTIL_SELECT), but now is being used for ONE_SELECT as well.

Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-02-11 20:08:52
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
Previous:From: Robert HaasDate: 2010-02-11 19:58:01
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group