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(at)postgresql(dot)org)
>