Re: generic plans and "initial" pruning
От | Amit Langote |
---|---|
Тема | Re: generic plans and "initial" pruning |
Дата | |
Msg-id | CA+HiwqEwDVn_Y_K-ZP2928MUN+hdW_cxw48a_2ZWNaWZiB667w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: generic plans and "initial" pruning (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Dec 5, 2024 at 2:32 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Tomas Vondra <tomas@vondra.me> writes: > > I'm not forcing you to do elog, if you think ereport() is better. I'm > > only asking because AFAIK the "policy" is that ereport is for cases that > > think can happen (and thus get translated), while elog(ERROR) is for > > cases that we believe shouldn't happen. > > The proposed coding looks fine from that perspective, because it uses > errmsg_internal and errdetail_internal which don't give rise to > translatable strings. Having said that, if we think this is a > "can't happen" case then it's fair to wonder why go to such lengths > to format it prettily. Also, I'd argue that the error message > style guidelines still apply, but this errdetail doesn't conform. Thinking about this further, perhaps an Assert is sufficient here. An Append/MergeAppend node's part_prune_index not pointing to the correct entry in the global "flat" list of PartitionPruneInfos would indicate a bug. It seems unlikely that user actions could cause this issue. -- Thanks, Amit Langote
В списке pgsql-hackers по дате отправления: