Re: [PATCH] [LARGE] select * from cursor foo

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] [LARGE] select * from cursor foo
Дата
Msg-id 11701.1001111182@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [PATCH] [LARGE] select * from cursor foo  (Alex Pilosov <alex@pilosoft.com>)
Ответы Re: [PATCH] [LARGE] select * from cursor foo
Список pgsql-hackers
Alex Pilosov <alex@pilosoft.com> writes:
>> Alex, could we have this resubmitted in "diff -c" format?  Plain diff
>> format is way too risky to apply.

> Resubmitted. In case list server chokes on the attachment's size, it is
> also available on www.formenos.org/pg/cursor.fix5.diff

I've looked this over, and I think it's not mature enough to apply at
this late stage of the 7.2 cycle; we'd better hold it over for more work
during 7.3.  Major problems:

1. Insufficient defense against queries that outlive the cursors they
select from.  For example, I could create a view that selects from a
cursor.  Yes, you check to see if the cursor name still exists ... but
what if that name now refers to a new cursor that delivers a completely
different set of columns?  Instant coredump.

2. I don't understand the semantics of queries that read cursors
that've already had some rows fetched from them.  Should we reset the
cursor to the start, so that all its data is implicitly available?
That seems strange, but if we don't do it, I think the behavior will be
quite unpredictable, since some join types are going to result in
resetting and re-reading the cursor multiple times anyway.  (You've
punted on this issue by not implementing ExecPortalReScan, but that's
not acceptable for a production feature.)

3. What does it mean to SELECT FOR UPDATE from a cursor?  I don't think
ignoring the FOR UPDATE spec is acceptable; maybe we just have to raise
an error.

4. Complete lack of documentation, including lack of attention to
updating the code's internal documentation.  (For instance, you seem
to have changed some of the conventions described in nodes/relation.h,
but you didn't fix those comments.)

The work you have done so far on changing RTE etc looks good ... but
I don't think the patch is ready to go.  Nor am I comfortable with
applying it now on the assumption that the problems can be fixed during
beta.

I realize you originally sent this in a month ago, and perhaps you would
have had time to respond to these concerns if people had reviewed the
patch promptly.  For myself, I can only apologize for not getting to it
sooner.  I've had a few distractions over the past month :-(
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: Further CVS errors
Следующее
От: Ned Wolpert
Дата:
Сообщение: anoncvs failure...