Re: [HACKERS] Updating column on row update

2009/11/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>

> CREATE OR REPLACE has got far safer semantics from the viewpoint of a
> script that wants to bull through without having any actual error
> handling (which is more or less the scenario we are arguing here, no?)
> After successful execution of the command you know exactly what
> properties the object has got.
>
> Whether it would be sensible to have CREATE OR REPLACE semantics for a
> language is something I'm not very clear on. It seems like changing any
> of the properties of a pg_language entry could be rather fatal from the
> viewpoint of an existing function using the language.
>
> [ thinks for awhile... ] Actually, CREATE LANGUAGE is unique among
> creation commands in that the common cases have no parameters, at least
> not since we added pg_pltemplate. So you could imagine defining CINE
> for a language as disallowing any parameters and having these semantics:
> * language not present -> create from template
> * language present, matches template -> OK, do nothing
> * language present, does not match template -> report error
> This would meet the objection of not being sure what the state is
> after successful execution of the command. It doesn't scale to any
> other object type, but is it worth doing for this one type?
>
> regards, tom lane
>

Actually, I prefer CREATE OR REPLACE over CINE, at least for the majority of
the creations, especially since it would be more consistent with what we
have for functions. If there must be an exception for languages, it would
make sense from what you describe above.

As for having plpgsql installed by default, are there any security
implications? If not, I can only see it as an advantage. At the moment
we're having to resort to a bit of a hack using a CASE statement in a plain
SQL function as mentioned earlier in this thread.

Thom