Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows
От | Tom Lane |
---|---|
Тема | Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows |
Дата | |
Msg-id | 28699.1223938889@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows ("Merlin Moncure" <mmoncure@gmail.com>) |
Ответы |
Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with
arrays of rows
Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows |
Список | pgsql-hackers |
"Merlin Moncure" <mmoncure@gmail.com> writes: > On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'm inclined to apply the patch with binary-coercibility adjustments >> and not try to turn RECORD or RECORD[] into full-fledged polymorphic >> types. It's not immediately clear what the use of that would be >> anyway. > ...meaning, that you would not be able to create a function taking > generic 'record' as a parameter? Well, you've never been able to do that, although for many of the PLs there doesn't seem to be any very fundamental reason why not. But I was actually wondering about something beyond that: should we have the equivalent of the polymorphic-type behaviors for composites? That would mean rules along the line of "all records mentioned in the call and result are the same composite type" and "record[] means the array type corresponding to whichever type record is". We don't seem to need these things in order to solve the recursion cycle detection problem, so I'm not very excited about pursuing the line of thought any further right now. > In that case I agree...any chance of > getting an updated patch? See CVS HEAD ... regards, tom lane
В списке pgsql-hackers по дате отправления: