From: Franco Bruno Borghesi <franco@akyasociados.com.ar>
Organization: AK y Asociados S.R.L.
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: function prepared plan
Date: Thu, 22 May 2003 12:04:11 -0300
User-Agent: KMail/1.5.1
References: <200303211910.01785.franco@akyasociados.com.ar>
	<13729.1053571544@sss.pgh.pa.us>
In-Reply-To: <13729.1053571544@sss.pgh.pa.us>
Cc: pgsql-sql@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200305221204.11126.franco@akyasociados.com.ar>

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