Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Date
Msg-id CAFj8pRAzj+m_u87YG3KYzCogiY1VOcP3k-1o3e+6t18ddArEQA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


2018-03-02 3:43 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:


2018-03-02 3:38 GMT+01:00 Andres Freund <andres@anarazel.de>:
On 2018-03-02 03:13:04 +0100, Pavel Stehule wrote:
> 2018-03-01 23:10 GMT+01:00 Andres Freund <andres@anarazel.de>:
>
> > On 2018-01-23 17:08:56 +0100, Pavel Stehule wrote:
> > > 2018-01-22 23:15 GMT+01:00 Stephen Frost <sfrost@snowman.net>:
> > > > This really could use a new thread, imv.  This thread is a year old and
> > > > about a completely different feature than what you've implemented here.
> > > >
> > >
> > > true, but now it is too late
> >
> > At the very least the CF entry could be renamed moved out the procedual
> > language category?
> >
>
> Why not?

Because the patch adds GUCs that don't have a direct connection
toprocedual languages?  And the patch's topic still says "plpgsql plan
cache behave" which surely is misleading.

Seems fairly obvious that neither category nor name is particularly
descriptive of the current state?


ok


> Have you idea, what category is best?

Server Features? Misc?  And as a title something about "add GUCs to
control custom plan logic"?


I'll move it there.

done

Pavel
 

Regards

Pavel

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: [HACKERS] plpgsql - additional extra checks
Next
From: Tom Lane
Date:
Subject: Re: heap_lock_updated_tuple_rec can leak a buffer refcount