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

On August 29, 2002 09:45 am, Tom Lane wrote:
> "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.

Exactly.

> > 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?

Well, magic (DWIM) parsing would be nice but this doesn't seem all that ugly 
to me.  One thing I do see though is that there is a completion issue.  Maybe 
we should specify that this can only happen within a transaction and add some 
code to the transaction handling.  Some simple rules (not to suggest that 
they are necessarily simple to implement of course) I see are;
1. An incomplete CREATE TYPE raises an error if not inside a transaction 
block.2. CREATE TYPE and CREATE FUNCTION will be backed out on an abort.3. Closing a transaction aborts if an
incompletetype has not been completed.
 

I think that this closes the loop without leaving functions defined on 
incomplete types.  With enough clever programming perhaps we can even make 
the incomplete declarion automatic when it is used in the CREATE FUNCTION.  
We just don't raise an error until the COMMIT.
 BEGIN TRANSACTION
 -- an incomplete type "chkpass" is conditionally created here CREATE FUNCTION chkpass_in(cstring) RETURNS chkpass;
 -- the existing conditional type is used here CREATE FUNCTION chkpass_out(chkpass) RETURNS cstring;
 -- define the actual type CREATE TYPE chkpass(input = chkpass_in, output = chkpass_out);
 END TRANSACTION

Does this make sense?

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.