Re: Proposal: make "opaque" obsolete - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: make "opaque" obsolete
Date
Msg-id 29478.1029872811@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: make "opaque" obsolete  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Responses Re: Proposal: make "opaque" obsolete
List pgsql-hackers
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> On Tue, 20 Aug 2002, Tom Lane wrote:
>> Less obviously, void_in should succeed (and return nothing
>> interesting, probably just a zero datum; it can ignore its input).  This
>> allows plpgsql functions to be defined to return VOID.

> Does this require additional work to the plpgsql grammar?

I suspect you'd need to say "return 0" (or return anything-at-all,
pretty much) to make it fly with the current plpgsql sources.  This
is a tad ugly but I think we can live with it until someone wants to
fix it.  If we have type void then for sure people will want to use
it for plpgsql functions; there are plenty of cases where you run a
plpgsql function just for side-effects.

> I think we should throw the notices right away, although this makes me
> wonder in general about upgrade path.  Are we ever planning to make that
> an error, and if so, how are we going to handle functions that are coming
> from previous versions where it was okay?

We can't make it an error until sufficiently far down the road that we
don't care about forward compatibility from 7.2-or-before dump files.
That'll be a long while, probably.

Throwing a notice right away is okay with me personally, but I wanted to
see what other people thought...
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Next
From: Tom Lane
Date:
Subject: Re: Large file support available