Re: PostgreSQL 9.6 behavior change with set returning (funct).*

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: PostgreSQL 9.6 behavior change with set returning (funct).*
Дата
Msg-id CAHyXU0zeaHigirhGXk5Go-=riu+ZSuiSa_kyLpgEaorSM8iAFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL 9.6 behavior change with set returning (funct).*  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PostgreSQL 9.6 behavior change with set returning (funct).*  (Stephen Frost <sfrost@snowman.net>)
Re: PostgreSQL 9.6 behavior change with set returning (funct).*  ("Regina Obe" <lr@pcorp.us>)
Список pgsql-hackers
On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> which is both SQL-standard semantics and much more efficient than
> SRF-in-tlist.  We've more or less deprecated SRF-in-tlist since we
> introduced LATERAL in 9.3.  How much are we willing to do to stay
> bug-compatible with old behaviors here?

I think we should, and the fact this was caught so early on the
release cycle underscores that.  One of the problems is that there are
reasonable cases (note, not impacted by this bug) of this usage that
are still commonplace, for example:

ysanalysis=# select unnest(current_schemas(true));  unnest
────────────pg_catalogpublic

I'm something of a backwards compatibility zealot, but I've become one
for very good reasons.  Personally, I'd rather we'd define precisely
the usages that are deprecated (I guess SRF-tlist in the presence of
FROM) and force them to error out with an appropriate HINT rather than
give a different answer than they used to.  The problem here is that
LATERAL is still fairly new and there is a huge body of code out there
leveraging the 'bad' way, as it was for years and years the only way
to do a number of useful things.

merlin



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Relation extension scalability
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: Relation extension scalability