On July 13 I wrote:
Yes, but I think the plugin is the right place to do it. What is more,
this won't actually prevent you completely from producing non-ECMAScript
compliant JSON, since json or jsonb values containing offending numerics
won't be caught, AIUI. But a fairly simple to write
On 07/17/2015 10:11 AM, Andrew Dunstan wrote:
On 07/17/2015 08:20 AM, Shulgin, Oleksandr wrote:
This patch makes Postgres core more complex
Yes, it does. But, that was not the purpose, obviously. :-)
while not really solving the problem in Javascript.
It still allows for less risk of
On Jul 17, 2015 4:31 PM, Andrew Dunstan and...@dunslane.net wrote:
On 07/17/2015 10:11 AM, Andrew Dunstan wrote:
On 07/17/2015 08:20 AM, Shulgin, Oleksandr wrote:
This patch makes Postgres core more complex
Yes, it does. But, that was not the purpose, obviously. :-)
while not really
On Jul 17, 2015 12:23 AM, Ryan Pedela rped...@datalanche.com wrote:
On Thu, Jul 16, 2015 at 11:51 AM, Robert Haas robertmh...@gmail.com
wrote:
I don't understand these issues in great technical depth, but if
somebody is arguing that it's OK for PostgreSQL to be difficult to use
for a certain
On 07/17/2015 08:20 AM, Shulgin, Oleksandr wrote:
This patch makes Postgres core more complex
Yes, it does. But, that was not the purpose, obviously. :-)
while not really solving the problem in Javascript.
It still allows for less risk of silent data corruption on the js side.
I have
Andrew Dunstan wrote:
I have already pointed out how this patch is fundamentally broken. You can
achieve your aims by a fairly small amount of code inside your logical
decoder, and with no core code changes whatsoever. So I'm puzzled why we are
even still debating this broken design.
I went
Shulgin, Oleksandr wrote:
On Jul 17, 2015 4:31 PM, Andrew Dunstan and...@dunslane.net wrote:
Incidentally, this doesn't look acceptable anyway:
! es-json_cxt.value(es-json_cxt, num, JSONTYPE_NUMERIC,
! NUMERICOID, 1702 /* numeric_out */);
We don't hardcode function oids elsewhere.
On 07/17/2015 10:30 AM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
I have already pointed out how this patch is fundamentally broken. You can
achieve your aims by a fairly small amount of code inside your logical
decoder, and with no core code changes whatsoever. So I'm puzzled why we are
On Wed, Jul 15, 2015 at 12:58 PM, Andrew Dunstan and...@dunslane.net wrote:
The approach take was both invasive and broken.
Well, then let's not do it that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
On Wed, Jul 15, 2015 at 1:10 PM, Ryan Pedela rped...@datalanche.com wrote:
Like I said previously, the
situation with Javascript will hopefully be remedied in a few years with ES7
anyway.
I don't understand these issues in great technical depth, but if
somebody is arguing that it's OK for
2015-07-16 19:51 GMT+02:00 Robert Haas robertmh...@gmail.com:
On Wed, Jul 15, 2015 at 1:10 PM, Ryan Pedela rped...@datalanche.com
wrote:
Like I said previously, the
situation with Javascript will hopefully be remedied in a few years with
ES7
anyway.
I don't understand these issues in
On 07/15/2015 10:52 AM, Robert Haas wrote:
On Mon, Jul 13, 2015 at 10:46 AM, Ryan Pedela rped...@datalanche.com wrote:
As far as large numbers in JSON, I think Postgres is doing the right thing
and should not be changed. It is Javascript that is stupid here, and I don't
think it is wise to add
On Wed, Jul 15, 2015 at 11:10 AM, Ryan Pedela rped...@datalanche.com
wrote:
On Wed, Jul 15, 2015 at 8:52 AM, Robert Haas robertmh...@gmail.com
wrote:
FWIW, I don't agree. If it's not easy to read the JSON that
PostgreSQL generates using JavaScript, then a lot of people are just
going to
On Wed, Jul 15, 2015 at 8:52 AM, Robert Haas robertmh...@gmail.com wrote:
FWIW, I don't agree. If it's not easy to read the JSON that
PostgreSQL generates using JavaScript, then a lot of people are just
going to give up on doing it, and IMO that would be sad. Telling
people that they have
On Mon, Jul 13, 2015 at 10:46 AM, Ryan Pedela rped...@datalanche.com wrote:
As far as large numbers in JSON, I think Postgres is doing the right thing
and should not be changed. It is Javascript that is stupid here, and I don't
think it is wise to add something to core just because one client
Yes, but I think the plugin is the right place to do it. What is more,
this won't actually prevent you completely from producing non-ECMAScript
compliant JSON, since json or jsonb values containing offending numerics
won't be caught, AIUI.
Ah, that's a good catch indeed.
But a fairly simple to
On 07/13/2015 05:41 AM, Shulgin, Oleksandr wrote:
On Mon, Jul 13, 2015 at 9:44 AM, Pavel Stehule
pavel.steh...@gmail.com mailto:pavel.steh...@gmail.com wrote:
To reiterate: for my problem, that is escaping numerics that
can potentially overflow[1] under ECMAScript standard, I
On 07/13/2015 10:46 AM, Ryan Pedela wrote:
On Mon, Jul 13, 2015 at 1:30 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de mailto:oleksandr.shul...@zalando.de
wrote:
To reiterate: for my problem, that is escaping numerics that can
potentially overflow[1] under ECMAScript standard,
On Mon, Jul 13, 2015 at 1:30 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de 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.
On Sun, Jul 12, 2015 at 8:39 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
The thing is - it's not only about whitespace, otherwise I would probably
not bother with the generic interface. For my original problem, there is
simply no way to do this correctly in an extension w/o copying over
2015-07-13 9:30 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de:
On Sun, Jul 12, 2015 at 8:39 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
The thing is - it's not only about whitespace, otherwise I would probably
not bother with the generic interface. For my original problem,
2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de
:
On Jul 11, 2015 8:41 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
There is simple rule - be strict on output and tolerant on input. If I
understand to sense of this patch - the target is one same format of JSON
On Sun, Jul 12, 2015 at 4:35 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr
oleksandr.shul...@zalando.de:
On Jul 11, 2015 8:41 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
There is simple rule - be strict on output and tolerant on
2015-07-12 20:11 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de
:
we talking about output - I can imagine, so there is only two
possibilities
- plain join, and pretty formatted join (but with only one style).
This makes sense. Postgres core really only needs to support the
we talking about output - I can imagine, so there is only two
possibilities
- plain join, and pretty formatted join (but with only one style).
This makes sense. Postgres core really only needs to support the
minimum styles necessary for core requirements. This means raw
unformatted json
On Fri, Jul 10, 2015 at 5:16 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
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
2015-07-11 18:02 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de
:
On Fri, Jul 10, 2015 at 5:16 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Well, one could call it premature pessimization due to dynamic call
overhead.
IMO, the fact that json_out_init_context() sets the
2015-07-11 19:57 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de
:
On Jul 11, 2015 6:19 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2015-07-11 18:02 GMT+02:00 Shulgin, Oleksandr
oleksandr.shul...@zalando.de:
On Fri, Jul 10, 2015 at 5:16 PM, Pavel Stehule
On Jul 11, 2015 6:19 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2015-07-11 18:02 GMT+02:00 Shulgin, Oleksandr
oleksandr.shul...@zalando.de:
On Fri, Jul 10, 2015 at 5:16 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Well, one could call it premature pessimization due to dynamic
forgotten attachment
Regards
Pavel
2015-07-10 14:34 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com:
Hi
I am sending review of this patch:
1. I reread a previous discussion and almost all are for this patch (me
too)
2. I have to fix a typo in hstore_io.c function (update attached),
2015-07-10 16:16 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de
:
On Fri, Jul 10, 2015 at 4:04 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2. why you did indirect call via JsonOutContext?
What is benefit
dst.value(dst, (Datum) 0, JSONTYPE_NULL, InvalidOid, InvalidOid,
Hi
I am sending review of this patch:
1. I reread a previous discussion and almost all are for this patch (me too)
2. I have to fix a typo in hstore_io.c function (update attached), other
(patching, regress tests) without problems
My objections:
1. comments - missing comment for some basic
2015-07-10 14:34 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com:
Hi
I am sending review of this patch:
1. I reread a previous discussion and almost all are for this patch (me
too)
2. I have to fix a typo in hstore_io.c function (update attached), other
(patching, regress tests)
2015-07-10 15:57 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de
:
2015-07-10 14:34 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com:
Hi
I am sending review of this patch:
1. I reread a previous discussion and almost all are for this patch (me
too)
2. I have to fix a typo in
On Fri, Jul 10, 2015 at 4:04 PM, Pavel Stehule pavel.steh...@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
2015-07-03 12:27 GMT+02:00 Heikki Linnakangas hlinn...@iki.fi:
On 05/27/2015 09:51 PM, Andrew Dunstan wrote:
On 05/27/2015 02:37 PM, Robert Haas wrote:
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de wrote:
Is it reasonable to add this patch to CommitFest
On 07/03/2015 06:27 AM, Heikki Linnakangas wrote:
On 05/27/2015 09:51 PM, Andrew Dunstan wrote:
On 05/27/2015 02:37 PM, Robert Haas wrote:
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de wrote:
Is it reasonable to add this patch to CommitFest now?
It's
On 05/27/2015 09:51 PM, Andrew Dunstan wrote:
On 05/27/2015 02:37 PM, Robert Haas wrote:
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de wrote:
Is it reasonable to add this patch to CommitFest now?
It's always reasonable to add a patch to the CommitFest if
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de wrote:
Is it reasonable to add this patch to CommitFest now?
It's always reasonable to add a patch to the CommitFest if you would
like for it to be reviewed and avoid having it get forgotten about.
There seems to be
On 05/27/2015 02:37 PM, Robert Haas wrote:
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de wrote:
Is it reasonable to add this patch to CommitFest now?
It's always reasonable to add a patch to the CommitFest if you would
like for it to be reviewed and avoid
On Sat, May 23, 2015 at 3:03 AM, Ryan Pedela rped...@datalanche.com wrote:
On Fri, May 22, 2015 at 10:51 AM, Merlin Moncure mmonc...@gmail.com
wrote:
On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andrew Dunstan wrote:
On 05/20/2015 09:16 AM, Shulgin,
On Fri, May 22, 2015 at 10:51 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andrew Dunstan wrote:
On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
Attached is a patch against master to generalize the
Andrew Dunstan wrote:
On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
Attached is a patch against master to generalize the JSON-producing
functions in utils/adt/json.c and to provide a set of callbacks which can
be overridden the same way that is already provided for *parsing* JSON.
I'm
On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andrew Dunstan wrote:
On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
Attached is a patch against master to generalize the JSON-producing
functions in utils/adt/json.c and to provide a set of callbacks which
On Wed, May 20, 2015 at 8:16 AM, Shulgin, Oleksandr
oleksandr.shul...@zalando.de wrote:
Hi, Hackers!
Attached is a patch against master to generalize the JSON-producing
functions in utils/adt/json.c and to provide a set of callbacks which can be
overridden the same way that is already
On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
Hi, Hackers!
Attached is a patch against master to generalize the JSON-producing
functions in utils/adt/json.c and to provide a set of callbacks which
can be overridden the same way that is already provided for *parsing*
JSON.
The
46 matches
Mail list logo
