Horton

Thread

Commits

  1. Remove the "opaque" pseudo-type and associated compatibility hacks.

  1. Is it time to retire type "opaque"?

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-03T17:10:15Z

    While looking at the proposed ALTER TYPE patch, I got annoyed
about the amount of cruft that exists in typecmds.c to deal with
ancient, non-type-safe ways of declaring type I/O functions.
The CREATE TYPE reference pages explains this well enough:

    Before PostgreSQL version 8.2, the shell-type creation syntax CREATE
    TYPE name did not exist. The way to create a new base type was to
    create its input function first. In this approach, PostgreSQL will
    first see the name of the new data type as the return type of the
    input function. The shell type is implicitly created in this
    situation, and then it can be referenced in the definitions of the
    remaining I/O functions. This approach still works, but is deprecated
    and might be disallowed in some future release. Also, to avoid
    accidentally cluttering the catalogs with shell types as a result of
    simple typos in function definitions, a shell type will only be made
    this way when the input function is written in C.

    In PostgreSQL versions before 7.3, it was customary to avoid creating
    a shell type at all, by replacing the functions' forward references to
    the type name with the placeholder pseudo-type opaque. The cstring
    arguments and results also had to be declared as opaque before 7.3. To
    support loading of old dump files, CREATE TYPE will accept I/O
    functions declared using opaque, but it will issue a notice and change
    the function declarations to use the correct types.

It might be too soon to drop the automatic-shell-type hack, but I think
a strong case can be made for dropping the automatic conversion of I/O
functions declared with OPAQUE.  7.3 was released in 2002, so any code
following the old way is now old enough to vote.  Does anyone really think
that a C function written against 7.2 or earlier would work in a modern
server without bigger changes than that?

The other remaining uses of OPAQUE are for old-style declarations of
trigger functions and language handler functions.  Again it seems very
unlikely that anyone still has code following the old style, or that
this'd be their biggest portability issue if they did.

In short, I propose ripping out OPAQUE entirely.

I wouldn't lobby too hard against removing the auto-shell-type hack
either, but it's not actually type-unsafe and it doesn't require
very much code to support, so the case for removing it seems a lot
weaker than that for getting rid of OPAQUE.

Thoughts?

			regards, tom lane

  2. Re: Is it time to retire type "opaque"?

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-03T23:39:26Z

    I wrote:
> In short, I propose ripping out OPAQUE entirely.

Like so...

I separated out the changes in CREATE TYPE because that's a bit
more complicated than the rest.  The behavior around shell types
gets somewhat simpler, and I moved the I/O function result type
checks into the lookup functions to make them all consistent.

			regards, tom lane

  3. Re: Is it time to retire type "opaque"?

    Andres Freund <andres@anarazel.de> — 2020-03-06T18:12:15Z

    Hi,

On 2020-03-03 12:10:15 -0500, Tom Lane wrote:
> In short, I propose ripping out OPAQUE entirely.

+1


> I wouldn't lobby too hard against removing the auto-shell-type hack
> either, but it's not actually type-unsafe and it doesn't require
> very much code to support, so the case for removing it seems a lot
> weaker than that for getting rid of OPAQUE.

I'm mildly in favor for for ripping those out too. I can't really
imagine there's a lot of users left, and they shouldn't be hard to
migrate. I don't think it'll get meaningfully fewer / easier if we just
wait another two years - seeems likely that auto shell type using code
isn't touched much.

Greetings,

Andres Freund