| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Making CASE error handling less surprising |
| Date: | 2020-07-23 20:56:44 |
| Message-ID: | 295996.1595537804@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Hm. Would SQL function inlining be a problem? It looks like that just
> substitutes parameters. Before calling
> eval_const_expressions_mutator(). So we'd not know not to evaluate such
> "pseudo constants". And that'd probably be confusing, especially
> because it's not exactly obvious when inlining happens.
Hm, interesting question. I think it might be all right without any
further hacking, because the parameters we care about substituting
would have been handled (or not) before inlining. But the interactions
would be ticklish, and surely worthy of a test case or three.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-07-23 21:09:54 | Re: Making CASE error handling less surprising |
| Previous Message | Andres Freund | 2020-07-23 20:49:12 | Re: Making CASE error handling less surprising |