Re: Making CASE error handling less surprising
От | Andres Freund |
---|---|
Тема | Re: Making CASE error handling less surprising |
Дата | |
Msg-id | 20200723204912.brclrpcwf3un2nmq@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Making CASE error handling less surprising (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Making CASE error handling less surprising
|
Список | pgsql-hackers |
Hi, On 2020-07-23 13:42:08 -0700, Andres Freund wrote: > On 2020-07-23 16:34:25 -0400, Tom Lane wrote: > > Andres Freund <andres@anarazel.de> writes: > > > It doesn't seem like it'd be too hard to implement that, but that it'd > > > probably be fairly bulky because we'd need to track more state across > > > recursive expression_tree_mutator() calls. > > > > It wouldn't be any harder than what I posted upthread; it would > > just be a different flag getting passed down in the context struct > > and getting tested in a different place. > > Cool. 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: