> 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
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.