Re: function prepared plan - Mailing list pgsql-sql

From Franco Bruno Borghesi
Subject Re: function prepared plan
Date
Msg-id 200305221204.11126.franco@akyasociados.com.ar
Whole thread Raw
In response to Re: function prepared plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: function prepared plan  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
Ok Tom, I'll try casting in the testSQL function like you said... but let me ask you another thing: 
what is plpgsql exactily caching?

I mean, in the real case, the testSQL function receives about 10 arguments, and based on theese 
arguments the function generates the SQL string with very diferent grouping criterias, joins and orders.

If plpgsql is caching the plan, I don't think the same plan will work with diferent parameters. Will just
casting datatypes do the work? Or should I directly use plctl?

Thanks.


On Wednesday 21 May 2003 23:45, you wrote:
> Franco Bruno Borghesi <franco@akyasociados.com.ar> writes:
> > Hi everyone! I have a little problem, and was wondering if anyone
> > could help me.
>
> Change the EXECUTEd query strings so that all the variants return TEXT,
> instead of trying to cast after-the-fact.
>
> If that doesn't seem reasonable, you might be better off working in
> pltcl.  plpgsql is designed on the assumption that it can cache query
> plans from one execution to the next, which is a good speed optimization
> but does require a certain amount of stability of datatypes.  If you'd
> prefer to kiss off speed for flexibility, pltcl is your tool.
>
> plpython might work too, but I'm not very familiar with it and couldn't
> say for certain.
>
>             regards, tom lane



pgsql-sql by date:

Previous
From: Luis Sousa
Date:
Subject: Re: Can arrays reference primary keys in CREATE TABLE?
Next
From: Tom Lane
Date:
Subject: Re: function prepared plan