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

From Andrew Dunstan
Subject Re: [GENERAL] Updating column on row update
Date
Msg-id 4B0A1812.30708@dunslane.net
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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [GENERAL] Updating column on row update  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers

Tom Lane wrote:
> [ 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?
>
>



I seriously doubt it. The only reason I could see for such a thing would
be to make it orthogonal with other CINE commands.

Part of the motivation for allowing inline blocks was to allow for
conditional logic. So you can do things like:

    DO $$

    begin
        if not exists (select 1 from pg_tables where schemaname = 'foo'
    and tablename = 'bar') then
           create table foo.bar (x int, y text);
        end if;
    end;

    $$;


It's a bit more verbose (maybe someone can streamline it) but it does
give you CINE (for whatever flavor of CINE you want), as well as lots
more complex possibilities than we can conceivably build into SQL.

cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Updating column on row update
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Updating column on row update