"D'Arcy J.M. Cain" <darcy@druid.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 entryCREATE TYPE chkpass;
-- make the I/O functionsCREATE FUNCTION chkpass_in(cstring) RETURNS chkpass ...;
CREATE FUNCTION chkpass_out(chkpass) RETURNS cstring ...;
-- replace shell entry with real oneCREATE 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