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 по дате отправления: