Vincenzo Romano <[EMAIL PROTECTED]> writes:
>
>> STABLE indicates that the function cannot modify the database,
> They talk about table scans which should not involce the information schema
> tables, the only tables that get modified by a fubction whose sole effect it
> to create other functions.
2007/5/31, Vincenzo Romano <[EMAIL PROTECTED]>:
Nonetheless your remark makes a lot of sense and I'm still in dubt.
In my case the "creatorfunc" has no parameters and returns void as it reads
data from configuration tables.
And it should be OK if ti were run only once.
AFAIK, the only practica
On Thursday 31 May 2007 13:23:36 Filip Rembiałkowski wrote:
> 2007/5/31, Vincenzo Romano <[EMAIL PROTECTED]>:
> > Hi all.
> >
> > Can functions whose effect is to create functions (yep!)
> > be labelled as "stable"?
>
> According to the docs, no.
>
> "STABLE indicates that the function cannot modif
2007/5/31, Vincenzo Romano <[EMAIL PROTECTED]>:
Hi all.
Can functions whose effect is to create functions (yep!)
be labelled as "stable"?
According to the docs, no.
"STABLE indicates that the function cannot modify the database (...)
any function that has side-effects must be classified volat
On Thu, Oct 12, 2006 at 10:34:30AM -0400, Tom Lane wrote:
> catalogs. I can only recall people ever asking for this feature in
> connection with the user/group catalogs, so covering those might be
> enough in practice; that'd certainly be lots less invasive than trying
> to make it work everywhere
Martijn van Oosterhout writes:
> On Wed, Oct 11, 2006 at 08:56:23PM +0200, Rafal Pietrak wrote:
>> Are there any plans for anything like that (referencing keys in system
>> tables from public schemas)?
> Not really. The primary objection is that every lookup in the backend
> on the system catalog
On Thu, Oct 12, 2006 at 12:38:08PM +0200, Rafal Pietrak wrote:
> My particular need was to have the ability to block the account until
> its password is changed. Which I believe might (at certain point) come
> into the main sources. But other applicatoins may have unforseen
> requirements - It woul
On Thu, 2006-10-12 at 11:47 +0200, Martijn van Oosterhout wrote:
> What may have a better chance is assigning triggers to commands (like ON
> CREATE USER) which trigger on specific situations. No-one serious
> considered implementing this though, at it's unclear what the use-case
> would be anyway.
On Wed, Oct 11, 2006 at 08:56:23PM +0200, Rafal Pietrak wrote:
> Apparently there is also no way to "foreign key reference" those, even
> without installing any on-delete actions/triggers.
>
> Pity.
>
> Are there any plans for anything like that (referencing keys in system
> tables from public sc
On Wed, 2006-10-11 at 10:30 -0400, Tom Lane wrote:
> > 1. I used the STABLE keyword to tell executor to evaluate the function
> > just once per statement.
>
> Wrong. STABLE is not a directive to the system, it is a promise about
> the behavior of your function ... and you're trying to break the
>
Rafal Pietrak <[EMAIL PROTECTED]> writes:
> 5. one of the procedures is:
> CREATE FUNCTION kill(text) RETURNS boolean as $$ SET ROLE
> MASTER_OF_THE_UNIVERSE; EXECUTE 'DROP USER ' || quote_ident($1); reset
> role; return true; END $$ LANGUAGE plpgsql STABLE;
You should use the SECURITY DEFINER pro
11 matches
Mail list logo
