On 2019-12-20 01:30, Vik Fearing wrote:
> On 16/12/2019 22:13, Tom Lane wrote:
>> That being the case, I'm not in favor of using up SQL syntax space for it
>> if we don't have to.
>
> Do I understand correctly that you are advocating *against* using
> standard SQL syntax for a feature that is defined by the SQL Standard
> and that we have no similar implementation for?
On the question of using SQL syntax or not for this, there are a couple
of arguments I'm considering.
First, the SQL standard explicitly permits not implementing the exact
signatures of the PTF component procedures; see feature code B208.
While this does not literally permit diverging on the CREATE FUNCTION
syntax, it's clear that they expect that the creation side of this will
have some incompatibilities. The existing practices of other vendors
support this observation. What's more interesting in practice is making
the invocation side compatible.
Second, set-returning functions in PostgreSQL already exist and in my
mind it would make sense to make this feature work with existing
functions or allow easy "upgrades" rather than introducing another
completely new syntax to do something very similar to what already
exists. This wouldn't be a good user experience. And the full standard
syntax is also complicated and different enough that it wouldn't be
trivial to add.
But I'm open to other ideas.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
