Re: [GENERAL] Updating column on row update - Mailing list pgsql-hackers

From Thom Brown
Subject Re: [GENERAL] Updating column on row update
Date
Msg-id bddc86150911230118o62a0326crddeb37ce71d3c602@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Updating column on row update  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] Updating column on row update
List pgsql-hackers
2009/11/23 Tom Lane <tgl@sss.pgh.pa.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

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: named generic constraints [feature request]
Next
From: Simon Riggs
Date:
Subject: Re: Partitioning option for COPY