Re: [HACKERS] merging some features from plpgsql2 project - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] merging some features from plpgsql2 project
Date
Msg-id CAFj8pRD641ZLpymw2UneA1UFggaAux4twEdVeVjnj41Yc1sqpQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] merging some features from plpgsql2 project  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] merging some features from plpgsql2 project  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


>>
>> >> *) Some user visible mechanic other than forcing SQL through EXECUTE
>> >> to be able to control plan caching would be useful.
>> >
>> > fully agree.
>> >
>> > Have you some ideas?
>> >
>> > What about plpgsql option (function scope) -- WITHOUT-PLAN-CACHE - any
>> > non
>> > trivial plans will not be cached - and evaluated as parametrized query
>> > only.
>>
>> I have slight preference for syntax marker for each query, similar to
>> INTO.  Maybe 'UNCACHED'?
>
>
> I am not clean opinion - the statement level is nice, but what readability?
>
> SELECT UNCACHED t.a, t.b FROM INTO a,b;

Yeah -- this is pretty ugly admittedly.  Maybe control directive is
ok, as long as you can set it mid function?

ADA uses for this purpose PRAGMA keyword - it is used for everything in ADA - cycle iteration optimization, ...the scope can be statement, block, procedure. 

so something like

BEGIN
  PRAGMA uncached_plans;
  SELECT ...
  ..
END;

But it should be verified by some PL/SQL or Ada experts

Little bit better - if PRAGMA is used in DECLARE part, then it has block scope

so some possible design can be:

DECLARE
  PRAGMA UNCACHED_PLANS;
BEGIN
  SELECT ... INTO ;
  SELECT ... INTO ;
END;

This respects Ada and PL/SQL style - probably easy implementation 

Regards

Pavel
 

Regards



 

merlin


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal: session server side variables