> -----Original Message-----
> From: Joe Conway [mailto:mail@joeconway.com] 
> Sent: Friday, August 09, 2002 4:04 PM
> To: Peter Eisentraut
> Cc: pgsql-hackers
> Subject: Re: [HACKERS] Proposal: stand-alone composite types
> 
> 
> 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;

Actually, the second looks a lot more natural to me.  As in most
programming languages, you define the type/class first, and then you can
use the type/class as an object.

Further, I don't want to have to remember the implementation details,
unless I need to dig into them.
So:

CREATE TYPE locator AS (First_Name varchar, Last_Name varchar, City
varchar, State_Province char(2), Country varchar);

CREATE FUNCTION CustomerList(varchar specification) RETURNS SETOF
locator;

Seems far more natural and convenient to me.

Fri, 9 Aug 2002 16:18:14 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Proposal: stand-alone composite types