Re: Proposal: make "opaque" obsolete

On Tue, 20 Aug 2002, Tom Lane wrote:

In general I think it sounds good, so I'm only responding to places where
I want to say something specific.

> I am not by any means wedded to the above type names; does anyone have
> suggestions for better names? (In particular, I am wondering if "tuple"
> and "internal" would be better named "pg_tuple" and "pg_internal". We
> might also consider making a type specifically named "trigger" and using
> that to declare trigger functions, rather than "tuple".)

I like something with trigger better, makes it very obvious that it's a
trigger function.

> An exception is that void_out should succeed and just return an empty string;
> this allows functions-returning-void to be called by SELECT and behave
> reasonably. 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? The
natural way to return from such a function (return;) doesn't seem like
it'd work without some changes. In any case I don't think this would
be necessary for 7.3.

> I am also considering allowing cstring_out to succeed (and, of course,
> just return a copy of what it's given). That would allow explicit invocation
> of an output function to work, viz "SELECT cash_out('42'::money)" would
> actually do what the user expects. This is not really necessary though.

I like the idea of cstring_out working, but I wonder if we should stop
users from calling the I/O functions directly anyway even if they were
made to be safe.

> Should we throw a NOTICE stating that opaque is deprecated if a trigger
> is declared with opaque? Or should we wait a release or two for that?
> Similarly, the preferred signature for I/O functions now uses cstring
> and the function's actual datatype, rather than OPAQUE (and again we
> could consider throwing a NOTICE).

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? It's relatively easy to do fix
ones that are currently used as trigger functions or type i/o functions,
but what about ones that aren't being used at dump time? Do we even need
to do anything?

> One of the original concerns about this was how to handle the circularity
> problem for user-defined I/O functions. If we don't do anything special,
> then it will still work as long as people define the input function first:
> create function foo_in(cstring) returns foo as ' ... ';
> -- you'll get a NOTICE here about "type foo is not yet defined"
> create function foo_out(foo) returns cstring as '...';
> -- you'll get another NOTICE here about "foo is only a shell"
> create type foo (input = foo_in, output = foo_out, ...);
> Are the notices annoying enough to be a problem? Is there a way around
> them?

I personally don't think it's a big deal, although I'm alot less annoyed
by notices than alot of people.