| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: SQL-standard function body |
| Date: | 2021-05-10 14:41:58 |
| Message-ID: | cfe5eac0-64ea-01d0-8ebc-94a16869490f@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2021-05-10 14:43:37 | Re: pg_stat_statements requires compute_query_id |
| Previous Message | Justin Pryzby | 2021-05-10 14:40:45 | Re: PG 14 release notes, first draft |