Type definition process (was Re: MemoryContextAlloc: invalid request size 1934906735)

"D'Arcy J.M. Cain" <darcy(at)druid(dot)net> writes:
> YES! Well, sort of. I didn't have any other operators but while I thought
> that both were the same (after all, I contributed it) someone must have fixed
> the one in CVS before adding it. The one I was working with had the
> operators working with chkpass on both sides. As soon as I fixed that it
> worked again.

Ah-hah, so vacuum was trying to use the "chkpass = text" operator to
compare two chkpass values. That explains the whole problem --- the
text code of course would take the first four bytes of the chkpass
string as a length word.

> In 7.2 the cstring and chkpass types fail in the function definitions because
> they have not been defined so I had to stay with opaque. In fact, how will
> that work in 7.3 anyway? We declare the functions to take or return a
> chkpass before we define it.

Yeah, you'll get warnings about the type not being defined yet, but it
will take them anyway. There's a fundamental circularity involved in
defining these things with any sort of accuracy, so we're going to have
to live with either warnings or kluges :-(.

I suppose that if the warnings really irritate people, we could think
about exposing the shell-type-entry mechanism more explicitly. For
example, if you did something like

-- make a shell pg_type entry
CREATE TYPE chkpass;

-- make the I/O functions
CREATE FUNCTION chkpass_in(cstring) RETURNS chkpass ...;

CREATE FUNCTION chkpass_out(chkpass) RETURNS cstring ...;

-- replace shell entry with real one
CREATE TYPE chkpass(input = chkpass_in, output = ...);

This looks rather ugly to me but it would be pretty easy to make it
work and not give any warnings. Comments?

regards, tom lane