Re: [PATCH] Generalized JSON output functions - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [PATCH] Generalized JSON output functions
Date
Msg-id CAFj8pRBoQUWZkRL12gFehseywzFrBEgn1GGq6mAkW5s=XYrb6Q@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Generalized JSON output functions  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Responses Re: [PATCH] Generalized JSON output functions
List pgsql-hackers


2015-07-10 16:16 GMT+02:00 Shulgin, Oleksandr <oleksandr.shulgin@zalando.de>:
On Fri, Jul 10, 2015 at 4:04 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
 
2. why you did indirect call via JsonOutContext?

What is benefit

dst.value(&dst, (Datum) 0, JSONTYPE_NULL, InvalidOid, InvalidOid, false);

instead

json_out_value(&dst, ....)

For consistency.  Even though we initialize the output context ourselves, there might be some code introduced between json_out_init_context() and dst.value() calls that replaces some of the callbacks, and then there would be a difference.
 
with this consistency? I didn't see this style everywhere in Postgres?  Isn't it premature optimization?
 
Well, one could call it premature pessimization due to dynamic call overhead.

IMO, the fact that json_out_init_context() sets the value callback to json_out_value is an implementation detail, the other parts of code should not rely on.  And for the Explain output, there definitely going to be *some* code between context initialization and output callbacks: these are done in a number of different functions.

Again - it is necessary? Postgres still use modular code, not OOP code. I can understand the using of this technique, when I need a possibility to change behave. But these function are used for printing JSON, not printing any others.

Pavel
 

--
Alex


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: creating extension including dependencies
Next
From: Alexander Korotkov
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive