Re: CREATE OR REPLACE FUNCTION

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-patches(at)postgresql(dot)org
Subject: Re: CREATE OR REPLACE FUNCTION
Date: 2001-09-22 04:31:03
Message-ID: 200109220431.f8M4V3326756@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

> Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> > Here's a patch I put together. I thought the Oracle-style 'CREATE OR
> > REPLACE FUNCTION' syntax might be useful to those doing lots of function
> > creation/development. It is against the 7.1.3 source.
>
> Hmm. There are a couple of things that are a tad ugly about this patch
> --- you should be heap_update'ing the pg_proc entry, not doing a delete
> and insert --- but the main thing I don't like is that there's no
> checking to ensure that the function return type doesn't change. We
> can't allow that; it'd break stored views etc that use the function.
>
> It'd probably also be a good idea to insist that the replacer be the
> same as the original owner. (Possibly RemoveFunction does that for you
> in the patch as it stands, but it'll need an explicit test if you go
> the update route.)
>
> BTW, I've been assuming that when we got around to providing a
> capability like this, it'd be via an "ALTER FUNCTION" kind of
> statement. Does anyone have a strong feeling pro or con on whether
> "CREATE OR REPLACE" is a preferable approach? It doesn't seem to
> fit with the spirit of our other maintenance commands, but maybe
> we should just bow down before the Oracle and do it their way...

I assume it preserves the function's OID? That is something we have
needed for a while because it would keep oid references to the function
the same, or at least we should give people the option of keeping the
oid.

On the REPLACE/ALTER discussion, we have CREATE TABLE and ALTER TABLE.
Seems ALTER FUNCTION is the way to go. Adding a REPLACE toplevel
keyword for this feature just seems too harsh.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2001-09-22 04:34:28 Re: JDBC test suite patch
Previous Message Bruce Momjian 2001-09-22 04:27:49 Re: Patch to pg_ctl to better support paths containing