Re: [REVIEW] prepare plans of embedded sql on function start - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [REVIEW] prepare plans of embedded sql on function start
Date
Msg-id 24053.1315695540@sss.pgh.pa.us
Whole thread Raw
In response to Re: [REVIEW] prepare plans of embedded sql on function start  (Marti Raudsepp <marti@juffo.org>)
List pgsql-hackers
Marti Raudsepp <marti@juffo.org> writes:
> On Sun, Sep 11, 2011 at 01:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not that happy with overloading the ANALYZE keyword to mean this
>> But we could certainly use some other name --- I'm
>> inclined to suggest CHECK:
>>        CHECK FUNCTION function_name(arglist);

> Just a thought: pg_check_function(oid)?

>> People would want some sort of wild card capability; at the very least
>> "check all plpgsql functions owned by me".

> SELECT pg_check_function(p.oid) FROM pg_proc p
> JOIN pg_user ON (usesysid=proowner) WHERE usename=current_user;

Hmm, there's something in what you say --- it gets us out from under the
need to anticipate what wildcard rules people would want.  I think it
loses something in ease-of-use, but we could have the utility command
too for the simple check-one-function case, and direct people to the
function as soon as they want something fancier.

What about check-strength options?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [WIP] Caching constant stable expressions per execution
Next
From: Thom Brown
Date:
Subject: Re: patch: Allow \dd to show constraint comments