Re: polymorphic table functions light

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: polymorphic table functions light
Date: 2019-12-20 03:55:10
Message-ID: 10559.1576814110@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> writes:
> 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?

My point is that what Peter is proposing is exactly *not* the standard's
feature. We generally avoid using up standard syntax for not-standard
semantics, especially if there's any chance that somebody might come along
and build a more-conformant version later. (Having said that, I had the
impression that what he was proposing wasn't the standard's syntax either,
but just a homegrown CREATE FUNCTION addition. I don't really see the
point of doing it like that when we can do it below the level of SQL.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Khandekar 2019-12-20 04:01:10 Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Previous Message Peter Geoghegan 2019-12-20 02:55:52 Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.