From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Brijesh Shrivastav" <Bshrivastav(at)esri(dot)com> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Issue with PQdescribePortal to describe a select cursor |
Date: | 2007-08-28 18:24:23 |
Message-ID: | 1056.1188325463@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
"Brijesh Shrivastav" <Bshrivastav(at)esri(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Brijesh Shrivastav | 2007-08-28 18:45:23 | Re: Issue with PQdescribePortal to describe a select cursor |
Previous Message | Brijesh Shrivastav | 2007-08-28 18:15:02 | Re: Issue with PQdescribePortal to describe a select cursor |