Re: Proposal: stand-alone composite types

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