| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: SQL-standard function body |
| Date: | 2021-04-08 05:41:40 |
| Message-ID: | 1820954.1617860500@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:
> Independent of this patch, it might be a good idea to have
> ExecInitParallelPlan() be robust against NULL querystrings. Places like
> executor_errposition() are certainly trying to be...
FWIW, I think the long-term drift of things is definitely that
we want to have the querystring available everywhere. Code like
executor_errposition is from an earlier era before we were trying
to enforce that. In particular, if the querystring is available in
the leader and not the workers, then you will get different error
reporting behavior in parallel query than non-parallel query, which
is surely a bad thing.
So IMO what you did here is definitely a short-term thing that
we should be looking to revert. The question at hand is why
Peter's patch broke this in the first place, and how hard it
will be to fix it properly. I'm entirely on board with reverting
the feature if that isn't readily fixable.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2021-04-08 05:46:26 | Re: SQL-standard function body |
| Previous Message | Amit Langote | 2021-04-08 05:33:31 | Re: ModifyTable overheads in generic plans |