Re: Common Table Expressions (WITH RECURSIVE) patch
От | Robert Haas |
---|---|
Тема | Re: Common Table Expressions (WITH RECURSIVE) patch |
Дата | |
Msg-id | 603c8f070809090647r4d4f50aq9480939074dc30e8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Common Table Expressions (WITH RECURSIVE) patch (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Common Table Expressions (WITH RECURSIVE) patch
|
Список | pgsql-hackers |
> 3. "I think this is a "must fix" because of the point about volatile > functions --- changing it later will result in user-visible semantics > changes, so we have to get it right the first time." > > I don't entirely agree with #3. It is user-visible, but only in the > sense that someone is depending on undocumented multiple-evaluation > behavior. What makes you think it's going to be undocumented? Single versus multiple evaluation is a keep aspect of this feature and certainly needs to be documented one way or the other. I can't understand why we would introduce a standard syntax with non-standard behavior, but if we do, it certainly had better be mentioned in the documentation. I think that the most likely result of a CTE implementation that doesn't guarantee single evaluation is that people simply won't use it. But anyone who does will expect that their queries will return the same results in release N and release N+1, for all values of N. The only way that an incompatible change of this type won't break people's applications is if they're not using the feature in the first place, in which case there is no point in committing it anyway. I wonder if the whole approach to this patch is backward. Instead of worrying about how to implement WITH RECURSIVE, maybe it would be better to implement a really solid, spec-compliant version of WITH, and add the RECURSIVE functionality in a later patch/release. ...Robert
В списке pgsql-hackers по дате отправления: