Re: SQL-standard function body - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: SQL-standard function body
Date
Msg-id cfe5eac0-64ea-01d0-8ebc-94a16869490f@enterprisedb.com
Whole thread Raw
In response to Re: SQL-standard function body  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SQL-standard function body
List pgsql-hackers
On 27.04.21 18:16, Tom Lane wrote:
> That's kind of a lot of complication, and inefficiency, for a corner case
> that may never arise in practice.  We've ignored the risk for default
> expressions, and AFAIR have yet to receive any field complaints about it.
> So maybe it's okay to do the same for SQL-style function bodies, at least
> for now.
> 
>> Another option would be that we disallow this at creation time.
> 
> Don't like that one much.  The backend shouldn't be in the business
> of rejecting valid commands just because pg_dump might be unable
> to cope later.

Since this is listed as an open item, I want to clarify that I'm 
currently not planning to work on this, based on this discussion. 
Certainly something to look into sometime later, but it's not in my 
plans right now.



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: PG 14 release notes, first draft
Next
From: Julien Rouhaud
Date:
Subject: Re: pg_stat_statements requires compute_query_id