On Wed, Jun 30, 2021 at 07:00:31PM -0400, Tom Lane wrote:
> If this code were new in v14, I'd be +1, but it looks like it was
> there in 13 too. So maybe there's somebody external depending on
> it, which would make it a bit unfriendly to remove it post-beta.
> Let's just add the #ifndef in HEAD.
Michael Paquier writes:
> On Wed, Jun 30, 2021 at 03:47:19PM +, Jacob Champion wrote:
>> But until/unless that is changed, an #ifndef seems like a good way to
>> prevent issues for the current code.
> Sounds sensible to do that as well for 14 before the release. Any
> thoughts about that?
I
On Wed, Jun 30, 2021 at 03:47:19PM +, Jacob Champion wrote:
> On Wed, 2021-06-30 at 11:03 -0400, Tom Lane wrote:
>> It does not look to me like json_errdetail can sensibly be used in
>> frontend, since it returns palloc'd strings in some paths and
>> constants in others. There'd be no way to a
On Wed, 2021-06-30 at 11:03 -0400, Tom Lane wrote:
> It does not look to me like json_errdetail can sensibly be used in
> frontend, since it returns palloc'd strings in some paths and
> constants in others. There'd be no way to avoid a memory leak
> in a frontend usage. So I think the dependency
Michael Paquier writes:
> Attached is a suggestion of patch to rework that a bit. Some extra
> elog()s could be added for the backend, as well as a new error code to
> use as default of report_parse_error(), but that does not seem to gain
> much. And this item looks independent of switching this
Hi all,
jsonapi.c includes the following code bits to enforce the use of
logging:
#ifdef FRONTEND
#define check_stack_depth()
#define json_log_and_abort(...) \
do { pg_log_fatal(__VA_ARGS__); exit(1); } while(0)
#else
#define json_log_and_abort(...) elog(ERROR, __VA_ARGS__)
#endif
This has bee
