Re: Proposal: stand-alone composite types

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: Proposal: stand-alone composite types
Дата
Msg-id 3D544A5B.9000204@joeconway.com
обсуждение исходный текст
Ответ на Re: Proposal: stand-alone composite types  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Proposal: stand-alone composite types
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Proposal: stand-alone composite types
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: Proposal: stand-alone composite types