Re: Proposal: stand-alone composite types - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Proposal: stand-alone composite types
Date
Msg-id 3D544A5B.9000204@joeconway.com
Whole thread Raw
In response to Re: Proposal: stand-alone composite types  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Proposal: stand-alone composite types  (Rod Taylor <rbt@zort.ca>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Proposal: stand-alone composite types
Next
From: Rod Taylor
Date:
Subject: Re: Proposal: stand-alone composite types