Re: Rewrite, normal execution vs. EXPLAIN ANALYZE
От | Bruce Momjian |
---|---|
Тема | Re: Rewrite, normal execution vs. EXPLAIN ANALYZE |
Дата | |
Msg-id | 201102171825.p1HIPIm16672@momjian.us обсуждение исходный текст |
Ответ на | Re: Rewrite, normal execution vs. EXPLAIN ANALYZE (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas wrote: > On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian <bruce@momjian.us> wrote: > > Tom Lane wrote: > >> Robert Haas <robertmhaas@gmail.com> writes: > >> > On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> >> I seriously doubt that there are many applications out there that are > >> >> actually depending on this aspect of rule execution; if anything, there > >> >> are probably more that will see it as a bug. > >> > >> > Changing EXPLAIN ANALYZE seems a bit less likely to break things for > >> > anyone depending on current behavior; > >> > >> Well, the point I was trying to make is that there may well be fewer > >> people depending on the current behavior than there are people for whom > >> the current behavior is wrong, only they don't know it because they've > >> not seen a failure (or not seen one often enough to diagnose what's > >> happening). > >> > >> This is of course merest speculation either way. ?But I don't feel that > >> we need to necessarily treat rule behavior as graven in stone. > > > > Where are we on this? ?It seems it is an issue independent of writable > > common table expressions (wCTEs). > > I believe that it's the same issue as this patch: > > https://commitfest.postgresql.org/action/patch_view?id=377 > > The status of that patch is that Tom promised to look at it two months > ago and hasn't. It would be nice if someone else could pick it up. > It's not good for our community to ignore patches that people have > taken the trouble to write and submit. Oh, at least it is in the current commit-fest and was not lost. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: