From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Thom Brown <thombrown(at)gmail(dot)com>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Updating column on row update |
Date: | 2009-11-23 14:31:50 |
Message-ID: | 603c8f070911230631j5425a1acu395d5ebcae2d5ef5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Sun, Nov 22, 2009 at 11:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> CREATE IF NOT EXISTS has been proposed and rejected before, more than
>>> once. Please see the archives.
>
>> Search for CINE to find the discussions. This is a good place to start:
>> http://archives.postgresql.org/pgsql-hackers/2009-05/msg00252.php
>
>> Despite Tom's assertions to the contrary, I am unable to find a clear
>> consensus against this feature in the archives,
>
> I think you didn't look back far enough --- that issue was settled years
> ago. IIRC the killer argument is that after CINE you do not know the
> state of the object: it exists, yes, but what properties has it got?
> If it already existed then it's still got its old definition, which
> might or might not be what you're expecting.
>
> 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.
Sure. I think that CINE only makes sense for objects for which COR
can't be implemented - things that have internal substructure, like
tables or tablespaces. I agree that there are pitfalls for the unwary
but I still think it's better than nothing. I understand that you
disagree.
> 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?
CREATE OR REPLACE seems like a better fit in this case. For example,
it seems plausible that someone might want to add an inline handler to
a procedural language that didn't have one without dropping and
recreating the language. Even changing the call handler seems like it
could be potentially useful in an upgrade scenario.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-23 14:38:34 | Re: [HACKERS] Updating column on row update |
Previous Message | A.Bhattacharya | 2009-11-23 14:10:29 | Error in Loading DLL using Postgres function |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-23 14:38:34 | Re: [HACKERS] Updating column on row update |
Previous Message | Tom Lane | 2009-11-23 14:30:58 | Re: Unicode UTF-8 table formatting for psql text output |