>
> 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 t
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
eve
Shulgin, Oleksandr wrote:
> On Jul 17, 2015 4:31 PM, "Andrew Dunstan" 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.
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 we
On Jul 17, 2015 4:31 PM, "Andrew Dunstan" 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. :-)
>>>
>>> > whil
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 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 hav
On Jul 17, 2015 12:23 AM, "Ryan Pedela" wrote:
>
> On Thu, Jul 16, 2015 at 11:51 AM, Robert Haas
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 category of user for several ye
On Thu, Jul 16, 2015 at 11:51 AM, Robert Haas 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 category of user for several years until the next
> language rev becomes mainstream, th
2015-07-16 19:51 GMT+02:00 Robert Haas :
> On Wed, Jul 15, 2015 at 1:10 PM, Ryan Pedela
> 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
> so
On Wed, Jul 15, 2015 at 1:10 PM, Ryan Pedela 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 PostgreSQL to be difficu
On Wed, Jul 15, 2015 at 12:58 PM, Andrew Dunstan 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 (pgsql-hackers@post
On Wed, Jul 15, 2015 at 11:10 AM, Ryan Pedela
wrote:
> On Wed, Jul 15, 2015 at 8:52 AM, Robert Haas
> 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 wou
On Wed, Jul 15, 2015 at 8:52 AM, Robert Haas 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 to parse the JSON u
On 07/15/2015 10:52 AM, Robert Haas wrote:
On Mon, Jul 13, 2015 at 10:46 AM, Ryan Pedela 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
On Mon, Jul 13, 2015 at 10:46 AM, Ryan Pedela 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 does
> stupid things
> 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 t
On 07/13/2015 10:46 AM, Ryan Pedela wrote:
On Mon, Jul 13, 2015 at 1:30 AM, Shulgin, Oleksandr
mailto: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 ove
On 07/13/2015 05:41 AM, Shulgin, Oleksandr wrote:
On Mon, Jul 13, 2015 at 9:44 AM, Pavel Stehule
mailto:pavel.steh...@gmail.com>> wrote:
To reiterate: for my problem, that is escaping numerics that
can potentially overflow[1] under ECMAScript standard, I want
to be abl
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 strin
On Mon, Jul 13, 2015 at 9:44 AM, Pavel Stehule
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 i
2015-07-13 9:30 GMT+02:00 Shulgin, Oleksandr :
> On Sun, Jul 12, 2015 at 8:39 PM, Pavel Stehule
> 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 correct
On Sun, Jul 12, 2015 at 8:39 PM, Pavel Stehule
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 all of
>> the logic
2015-07-12 20:11 GMT+02:00 Shulgin, Oleksandr
:
> > > 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
> > 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
> unformatte
On Sun, Jul 12, 2015 at 4:35 AM, Pavel Stehule wrote:
>
>
> 2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr
> :
>>
>> On Jul 11, 2015 8:41 PM, "Pavel Stehule" wrote:
>> >
>> > There is simple rule - be strict on output and tolerant on input. If I
>> > understand to sense of this patch - the target
2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr
:
> On Jul 11, 2015 8:41 PM, "Pavel Stehule" 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
> documents - so there are no space for any
On Jul 11, 2015 8:41 PM, "Pavel Stehule" 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
documents - so there are no space for any variability.
So, would you prefer explain json format on a
2015-07-11 19:57 GMT+02:00 Shulgin, Oleksandr
:
> On Jul 11, 2015 6:19 PM, "Pavel Stehule" 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
> wrote:
>
>
> Well, one cou
On Jul 11, 2015 6:19 PM, "Pavel Stehule" 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
wrote:
Well, one could call it premature pessimization due to dynamic call
overhead.
2015-07-11 18:02 GMT+02:00 Shulgin, Oleksandr
:
> On Fri, Jul 10, 2015 at 5:16 PM, Pavel Stehule
> 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
On Fri, Jul 10, 2015 at 5:16 PM, Pavel Stehule
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 code should
>>
2015-07-10 16:16 GMT+02:00 Shulgin, Oleksandr
:
> On Fri, Jul 10, 2015 at 4:04 PM, Pavel Stehule
> wrote:
>
>>
>>>
2. why you did indirect call via JsonOutContext?
>
> What is benefit
>
> dst.value(&dst, (Datum) 0, JSONTYPE_NULL, InvalidOid, InvalidOid,
> false);
>
>
On Fri, Jul 10, 2015 at 4:04 PM, Pavel Stehule
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
2015-07-10 15:57 GMT+02:00 Shulgin, Oleksandr
:
> 2015-07-10 14:34 GMT+02:00 Pavel Stehule :
>>
>>> 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 (updat
>
> 2015-07-10 14:34 GMT+02:00 Pavel Stehule :
>
>> 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 p
forgotten attachment
Regards
Pavel
2015-07-10 14:34 GMT+02:00 Pavel Stehule :
> 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,
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 API
2015-07-03 12:27 GMT+02:00 Heikki Linnakangas :
> 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
>>> wrote:
>>>
Is it reasonable to add this patch to CommitFest now?
>>> It's alw
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
wrote:
Is it reasonable to add this patch to CommitFest now?
It's always reasonable to add a patch
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
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 rev
On 05/27/2015 02:37 PM, Robert Haas wrote:
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
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.
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
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 some disagreement about whe
On Sat, May 23, 2015 at 3:03 AM, Ryan Pedela wrote:
> On Fri, May 22, 2015 at 10:51 AM, Merlin Moncure
> wrote:
>
>> On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
>> wrote:
>> > Andrew Dunstan wrote:
>> >>
>> >> On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
>> >
>> >> >Attached is a patch
On Fri, May 22, 2015 at 10:51 AM, Merlin Moncure wrote:
> On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
> 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 i
On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
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 can
>> >be over
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
On Thu, May 21, 2015 at 6:43 PM, Merlin Moncure wrote:
> On Thu, May 21, 2015 at 2:23 AM, Shulgin, Oleksandr
> wrote:
> > On Wed, May 20, 2015 at 4:06 PM, Merlin Moncure
> wrote:
> >>
> >> On Wed, May 20, 2015 at 8:16 AM, Shulgin, Oleksandr
> >> wrote:
> >> >
> >> > a) no spaces
> >> >
> >> >
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 motivatio
On Wed, May 20, 2015 at 8: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.
>
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 motivation behind this to be able to produce specially-crafted JSO
51 matches
Mail list logo
