Re: [PATCH] Generalized JSON output functions

Поиск
Список
Период
Сортировка
От Shulgin, Oleksandr
Тема Re: [PATCH] Generalized JSON output functions
Дата
Msg-id CACACo5Q3jzN5FiWeE31rSW4Ld5vk8TZv3U8b62pQgrupPvNP0A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Generalized JSON output functions  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: [PATCH] Generalized JSON output functions  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Mon, Jul 13, 2015 at 9:44 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

To reiterate: for my problem, that is escaping numerics that can potentially overflow[1] under ECMAScript standard, I want to be able to override the code that outputs the numeric converted to string.  There is no way in current implementation to do that *at all*, short of copying all the code involved in producing JSON output and changing it at certain points.  One could try re-parsing JSON instead, but that doesn't actually solve the issue, because type information is lost forever at that point.

The whitespace unification was a mere side-effect of the original effort on this patch.

The dynamic type change is some what I would not to do in database, really :)

If you afraid about overflow, then convert numeric to string immediately - in this case, the client have to support both variant - so immediate cast should not be a problem.

Yeah, but how would you do that in context of a logical replication decoding plugin?  I've tried a number of tricks for that, including, but not limited to registering phony types to wrap numeric type and replacing the OID of numeric with this custom type OID in TupleDesc, but then again one has to register that as known record type, etc.

Anyway this check on max number should be implemented in our JSON(b) out functions (as warning?).

Not really, since this is a problem of ECMAScript standard, not JSON spec.  For example, Python module for handling JSON doesn't suffer from this overflow problem,

The thing is, we cannot know which clients are going to consume the stream of decoded events, and if it's some implementation of JavaScript, it can suffer silent data corruption if we don't guard against that in the logical decoding plugin.

Hope that makes it clear. :-)

--
Alex

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: multivariate statistics / patch v7
Следующее
От: Ildus Kurbangaliev
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive