Re: Proposal: stand-alone composite types

I think it buys the same as SERIAL does for sequences.

Is it likely to have more than one function using a complex type like
that?  If not, then allowing it's creation (not enforcing) could be
useful.


On Fri, 2002-08-09 at 19:03, Joe Conway wrote:
> Peter Eisentraut wrote:
> > Joe Conway writes:
> >>3. Modify CREATE FUNCTION to allow the implicit creation of a dependent
> >>    composite type, e.g.:
> > 
> > Forgive this blunt question, but:  Why?
> 
> Now's a *great* time for a blunt question because I haven't started 
> actively working on this yet. Much better than after I'm done.  ;-)
> 
> 
> > Of course I can see the answer, it's convenient, but wouldn't the system
> > be more consistent overall if all functions and types are declared
> > explicitly?
> > 
> 
> And of couse you are correct. It is almost purely convenience. My 
> reasoning was this: if I am creating a function which returns a 
> composite type, then the fact that a named composite type exists is 
> superfluous to me. It would be more natural for me to do:
> 
>     CREATE FUNCTION foo() RETURNS SETOF (f1 int, f2 text);
> 
> than to do:
> 
>     CREATE TYPE some_arbitrary_name AS (f1 int, f2 text);
>     CREATE FUNCTION foo() RETURNS SETOF some_arbitrary_name;
> 
> But I admit it is only a "nice-to-have", not a "need-to-have".
> 
> How do others feel? Do we want to be able to implicitly create a 
> composite type during function creation? Or is it unneeded bloat?
> 
> I prefer the former, but don't have a strong argument against the latter.
> 
> Joe
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>