Re: function prepared plan

From: Franco Bruno Borghesi <franco(at)akyasociados(dot)com(dot)ar>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: function prepared plan
Date: 2003-05-22 15:04:11
Message-ID: 200305221204.11126.franco@akyasociados.com.ar
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)akyasociados(dot)com(dot)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

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2003-05-22 15:15:44 Re: function prepared plan
Previous Message David W Noon 2003-05-22 13:54:12 Re: Really simple SQL problem