From: Tom Lane <tgl@sss.pgh.pa.us>
To: Brijesh Shrivastav <Bshrivastav@esri.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Issue with PQdescribePortal to describe a select cursor
Date: Tue, 28 Aug 2007 14:24:23 -0400
Message-ID: <1056.1188325463@sss.pgh.pa.us> (raw)
In-Reply-To: <5774D66D5EC83645A99B3A905527BB7102933EE6@zipwire.esri.com>
References: <5774D66D5EC83645A99B3A905527BB7102933EE6@zipwire.esri.com>
"Brijesh Shrivastav" <Bshrivastav@esri.com> writes:
> My problem in executing a portal before I can describe is the way
> our client api interface is defined. Typically user sends us a query
> that we prepare and describe before sending the describe output
> back to the client. In next step user provides us with any input
> parameter data for the sql and ask us to execute the query. This
> system works well with PQprepare/PQdescribePrepared but doesn't
> give me the advantage of a portal. One option that will have a
> performance penalty will be to prepare the statement without creating
> a portal during initial query so I can send describe results back
> to the client and only create the portal during the execute. I will
> pay the cost of preparing query twice though I can set LIMIT to 0
> for the initial query to possibly reduce the prepare time.
You seem to be confusing preparing a query with executing it. LIMIT 0
isn't going to save any prepare time.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, Bshrivastav@esri.com
Subject: Re: Issue with PQdescribePortal to describe a select cursor
In-Reply-To: <1056.1188325463@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox