> On Fri, Sep 22, 2017 at 3:51 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 9/21/17 11:24, Dmitry Dolgov wrote:
>> One last thing that I need to clarify. Initially there was an idea to
>> minimize changes in `pg_type`
>
> I see, but there i
> On 31 July 2017 at 07:49, Thomas Munro
wrote:
>> On Sun, Jul 30, 2017 at 7:07 AM, Dmitry Dolgov <9erthali...@gmail.com>
wrote:
>>
>> I looked through the code of `synchronous-replay-v1.patch` a bit and ran
a few
>> tests. I didn't manage to break anything,
> On 20 September 2017 at 17:19, Arthur Zakirov
wrote:
> As a conclusion:
> * additional field are needed to pg_type for *_fetch and *_assign
functions to solve dependency problem
One last thing that I need to clarify. Initially there was an idea to
minimize
changes in `pg_type` - that's why I ad
> On 19 September 2017 at 10:21, Arthur Zakirov
wrote:
> On Mon, Sep 18, 2017 at 12:25:04PM +0200, Dmitry Dolgov wrote:
>> > I think it would be good to add new catalog table. It may be named as
>> pg_type_sbs or pg_subscripting (second is better I think).
>> >
> On 18 September 2017 at 11:39, Arthur Zakirov
wrote:
> I think it would be good to add new catalog table. It may be named as
pg_type_sbs or pg_subscripting (second is better I think).
> This table may have the fields:
> - oid
> - sbstype
> - sbsinit
> - sbsfetch
> - sbsassign
What is `sbstype`?
> On 17 September 2017 at 23:34, Arthur Zakirov
wrote:
>
> I have put some thought into it. What about the following syntax?
>
> CREATE SUBSCRIPTING FOR type_name
> INITFUNC = subscripting_init_func
> FETCHFUNC = subscripting_fetch_func
> ASSIGNFUNC = subscripting_assign_func
> DROP SUBSCRIP
> On 17 September 2017 at 00:04, Arthur Zakirov
wrote:
>
> In my opinion, 'DEPENDS ON' syntax is not actually appropriate here. It
> also looks like a not very good hack to me.
Hm...why do you think about it as a hack?
> Moreover user can implement subscripting to its own type without using
> 'D
> On 11 September 2017 at 23:45, Tom Lane wrote:
>
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> >> On 11 September 2017 at 23:19, Tom Lane wrote:
> >> Uh, what? Sure you can. Just because the existing code never has a
> >> reason to create such
> On 11 September 2017 at 23:19, Tom Lane wrote:
>
> Uh, what? Sure you can. Just because the existing code never has a
> reason to create such a dependency doesn't mean it wouldn't work.
Well, I thought that `pg_depend` was not intended to be used from
user-defined
code and it's something "int
> On 9 September 2017 at 23:33, Arthur Zakirov
wrote:
> PostgreSQL and documentation with the patch compiles without any errors.
All
> regression tests passed.
Thank you!
> But honestly I still cannot say that I agree with *_extract() and
*_assign()
> functions creation way. For example, there i
> On 7 September 2017 at 15:46, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> It seems that for this particular workload it was about 20-25% slower.
Hmm...looks like I provided misleading data, sorry. The numbers from
previous
email are correct and I'm able to reproduce th
> On 8 September 2017 at 01:32, Magnus Hagander wrote:
>
> 1. where was stderr actually sent? To the console, to /dev/null or to a
file?
To the console (but I can also try other options, although I'm not sure if
it would have any impact).
> 2. Could you run the same thing (on the same machine) w
Hi
> On 31 August 2017 at 14:49, Tom Lane wrote:
>> Are you actually asking for a benchmark of if logging gets slower?
>
> Yes.
>
>> If so,
>> could you suggest a workload to make an actual benchmark of it (where
>> logging would be high enough that it could be come a bottleneck -- and
not
>> wri
> On 12 July 2017 at 23:45, Thomas Munro
wrote:
> I renamed it to "synchronous replay", because "causal reads" seemed a bit
too
> arcane.
Hi
I looked through the code of `synchronous-replay-v1.patch` a bit and ran a
few
tests. I didn't manage to break anything, except one mysterious error that
I
> On 20 July 2017 at 16:24, David Fetter wrote:
>
> If we can agree to a definition, we can make this go. My vague
> memories from graph theory indicate that that "agree to a definition"
> part is the real problem to be solved.
I tried to embody some relevant thoughts in this thread [1], I think
Hi
As far as I know, since 9.5 we're missing some convenient features, namely a
deepversion of `jsonb_concat` and `jsonb_minus`. There are already few
feature
requests about `jsonb_minus` (see [1], [2]) and a lot of confusion and
requests
about a deep version of `jsonb_concat`. From my point of vi
> On 23 June 2017 at 13:48, Thomas Munro
wrote:
>
> Apologies for the extended delay. Here is the rebased patch, now with a
> couple of improvements (see below).
Thank you. I started to play with it a little bit, since I think it's an
interesting idea. And there are already few notes:
* I don't
> On 29 Jun 2017 08:18, "Yugo Nagata" wrote:
>
> This is because this function is defined as strict
Yes, I realized that few moments after I sent my message.
> Arg type is needed.
>
> =# grant execute on function pg_reload_backend(int) to test_user;
Oh, I see, thank you.
> On 28 June 2017 at 12:17, Yugo Nagata wrote:
>
> Hi,
>
> Attached is a patch of pg_reload_backend that is a function signaling
> SIGHUP to a specific backend. The original idea is from Michael
Paquier[1].
> The documatation isn't included in this patch yet.
I have few questions. I'm curious, wh
> On 20 May 2017 at 10:03, Pavel Stehule wrote:
>
> Now concat is 2x times slower than || operator. With cached FmgrInfo for
> output function it will be only 5%.
Looks nice and does what's expected (what else one may need from a Saturday
evening). I just can mention that from what I see the prev
> On 26 May 2017 at 23:05, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> > On 5/25/17 19:16, Petr Jelinek wrote:
> >> The reported error is just one of many errors that can happen when DROP
> >> SUBSCRIPTION tries to drop the slot (doens't exist, still active, no
> >> permission,
On 23 May 2017 at 07:26, Euler Taveira wrote:
>
> ReplicationSlotValidateName() should be called in
parse_subscription_options() to avoid a pilot error.
> IMHO we should prevent a future error (use of invalid slot name).
Yes, I see now. I assume this little patch should be enough for that.
diff -
Hi
Maybe this question was already raised before, but I couldn't find a
discussion. When I'm creating a subscription with `create_slot=false` looks
like it's possible to pass a slot name with invalid characters. In this
particular case both publisher and subscriber were on the same machine:
=
Hi
I'm wondering about status of this patch and how can I try it out?
> On 3 January 2017 at 02:43, Thomas Munro
wrote:
> The replay lag tracking patch this depends on is in the current commitfest
I assume you're talking about this patch [1] (at least it's the only thread
where I could find a `
On 13 May 2017 at 22:22, Tom Lane wrote:
>
> Apparently you are not testing against current HEAD. That's been there
> since d10c626de (a whole two days now ;-))
Indeed, I was working on a more than two-day old antiquity. Unfortunately,
it's even more complicated
to apply this patch against the c
Hi
> On 4 April 2017 at 19:13, Masahiko Sawada wrote:
>
> Other than that issue current patch still could not pass 'make check'
> test of contrib/test_decoding.
Just a note about this patch. Of course time flies by and it needs rebase,
but also there are few failing tests right now:
* one that
Hi
Recently I noticed, that when I'm running the regression tests under
Valgrind 3.9.0,
one test for `numeric` is constantly failing:
Here is what expected:
```
SELECT i as pow,
round((-2.5 * 10 ^ i)::numeric, -i),
round((-1.5 * 10 ^ i)::numeric, -i),
round((-0.5 * 10 ^ i)::numeric, -i),
round((0
> On 4 May 2017 at 20:05, Magnus Hagander wrote:
>
> PFA a patch that adds a new function, pg_move_replication_slot, that
makes it
> possible to move the location of a replication slot without actually
> consuming all the WAL on it.
Just a few questions just a few questions out of curiosity:
* d
On 31 March 2017 at 00:01, Andrew Dunstan
wrote:
>
> I have just noticed as I was writing/testing the non-existent docs for
> this patch that it doesn't supply variants of to_tsvector that take a
> regconfig as the first argument. Is there a reason for that? Why
> should the json(b) versions be di
On 30 March 2017 at 19:36, Arthur Zakirov wrote:
>
> The last point is about the tutorial. As Tom pointed it is not useful
when the tutorial doesn't execute. It happens because there is not "custom"
type in subscripting.sql.
I'm confused. Maybe I'm missing something, but there is "custom" type in
> On 29 March 2017 at 18:28, Andrew Dunstan
wrote:
>
> These patches seem fundamentally OK. But I'm still not happy with the
> naming etc.
I've changed names for all functions and action definitions, moved out the
changes in header file to `jsonapi.h` and removed `is_jsonb_data` macro. So
it
shou
On 28 March 2017 at 11:58, Arthur Zakirov wrote:
>
> Your patch reverts commits from 25-26 march. And therefore contains 15000
lines.
Wow, I didn't notice that, sorry - will fix it shortly.
> I'm not through looking at this. However, here are a few preliminary
comments
I've attached new versions of the patches with improvements related to
these commentaries.
diff --git a/src/backend/tsearch/to_tsany.c b/src/backend/tsearch/to_tsany.c
index 6e5de8f..8f7bcfe 100644
--- a/src/backend/ts
On 24 March 2017 at 15:39, David Steele wrote:
>
> Do you have an idea when you will have a patch ready?
Yes, I'll prepare a new version with most important changes in two days.
> On 21 March 2017 at 03:03, Andrew Dunstan
wrote:
>
> However, I think it should probably be broken up into a couple of pieces -
> one for the generic json/jsonb transforms infrastructure (which probably
> needs some more comments) and one for the FTS functions that will use it.
Sure, here are t
> On 21 March 2017 at 18:16, David Steele wrote:
>
> This thread has been idle for over a week.
Yes, sorry for the late reply. I'm still trying to find a better solution
for
some of the problems, that arose in this patch.
> On 15 March 2017 at 00:10, Tom Lane wrote:
> Dmi
> On 28 February 2017 at 19:21, Oleg Bartunov wrote:
> 1. add json support
I've added json support for all functions.
> Its_headline should returns the original json with highlighting
Yes, I see now. I don't think it's worth it to add a special option for that
purpose, so I've just changed th
Hi all
I would like to propose patch with a set of new small functions for fts in
case of
jsonb data type:
* to_tsvector(config, jsonb) - make a tsvector from all string values and
elements of jsonb object. To prevent the situation, when tsquery can find
a
phrase consisting of lexemes from tw
On 24 January 2017 at 02:36, Tom Lane wrote:
> It might be possible to get away with having only one pg_type column,
> pointing at the parse-analysis function. That function would generate
> a SubscriptingRef tree node containing the OID of the appropriate
> execution function, which execQual.c
> On 24 January 2017 at 02:07, Tom Lane wrote:
> I took an extremely quick look over the patch
Thank you for the feedback. It took some time for me to think about all
suggestions and notes.
> 1. As I mentioned previously, it's a seriously bad idea that ArrayRef
> is used for both array subscript
> On 4 January 2017 at 18:06, Artur Zakirov
wrote:
> But I'm not convinced about how to distinguish ArrayRef node with new
> SubscriptingRef node.
I'm not sure I understood you correctly. You're talking about having two
nodes
`ArrayRef` and `SubscriptingRef` at the same time for the sake of backw
, 2016 at 10:56 PM, Dmitry Dolgov
<9erthalion6(at)gmail(dot)com>
> wrote:
>
> > On 15 November 2016 at 15:03, Aleksander Alekseev <
> a(dot)alekseev(at)postgrespro(dot)ru> wrote:
> > Hello.
> >
> > I took a look on the latest -v4 patch. I would like to n
> On 5 December 2016 at 12:03, Haribabu Kommi
wrote:
> > Moved to next CF with "needs review" status.
Looks like we stuck here little bit. Does anyone else have any
suggestions/improvements, or this patch is in good enough shape?
> Attached is an implantation of jsonb_delete that instead of taking a
single key to remove accepts an array of keys
Since I already saw this patch, here is my small review.
Speaking about implementation of `jsonb_delete_array` - it's fine, but I
would like to suggest two modifications:
* create
> On 15 November 2016 at 22:53, Magnus Hagander wrote:
> Attached is an implantation of jsonb_delete that instead of taking a
single key to remove accepts an array of keys (it still does just keys, so
it's using the - operator, it's not like the path delete function that also
takes an array, but u
> On 15 November 2016 at 15:03, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
> Hello.
>
> I took a look on the latest -v4 patch. I would like to note that this
> patch breaks a backward compatibility. For instance sr_plan extension[1]
> stop to compile with errors
Thank you for the feed
On 5 October 2016 at 03:00, Oleg Bartunov wrote:
>
> have you ever run 'make check' ?
>
> =
> 53 of 168 tests failed.
> =
>
>
Sure, how else could I write tests for this feature? But right now on my
machine
everything is ok (the same for `make inst
Hi
I tried to dig into this patch (which seems pretty interesting) to help
bring
it in good shape. Here are few random notes, I hope they can be helpful:
> I think we actually need a real API here.
Definitely, there are plenty places in the new code with the same pattern:
* figure out if it's a
Hi
With regard to previous conversations:
http://www.postgresql.org/message-id/flat/CA+q6zcV8qvGcDXurwwgUbwACV86Th7G80pnubg42e-p9gsSf=g...@mail.gmail.com#CA+q6zcV8qvGcDXurwwgUbwACV86Th7G80pnubg42e-p9gsSf=g...@mail.gmail.com
http://www.postgresql.org/message-id/flat/ca+q6zcx3mdxgcgdthzuyswh-apyhh
On 6 April 2016 at 03:29, Andrew Dunstan wrote:
>
> Yeah, keeping it but rejecting update of an existing key is my preference
> too.
>
> cheers
>
> andrew
>
Yes, it sounds quite reasonable. Here is a new version of patch (it will
throw
an error for an existing key). Is it better now?
diff --git
On 31 March 2016 at 17:31, Vitaly Burovoy wrote:
> it is logical to insert new value if "before", then current value, then new
> value if "after".
>
Oh, I see now. There is a slightly different logic: `v` is a current value
and `newval` is a new value.
So basically we insert a current item in ca
On 31 March 2016 at 05:04, Vitaly Burovoy wrote:
> The documentation changes still has to be fixed.
>
Thanks for help. Looks like I'm not so good at text formulation. Fixed.
> Moreover it seems the logic in the code is correct
No - I see now, that I made the same mistake in two places (e.g.
Here is a new version of path, I hope I didn't miss anything. Few notes:
> 4.
> or even create a new constant (there can be better name for it):
> #define JB_PATH_CREATE_OR_INSERT (JB_PATH_INSERT_BEFORE |
> JB_PATH_INSERT_AFTER | JB_PATH_CREATE)
Good idea, thanks.
> 5.
> > if (op_type != JB_PATH
> Do you have an updated patch ready?
No, I'm afraid it will not be ready for Monday.
> I still don't like that this works on path leading to an object given
that we can't fulfill the promise of inserting to an arbitrary position
there.
I'm thinking about this following way - `jsonb_insert` is just a function
to insert a new value, which has specific options to enforce arbitrary
po
Hi Vitaly, thanks for the review. I've attached a new version of path with
improvements. Few notes:
> 7. Why did you remove "skip"? It is a comment what "true" means...
Actually, I thought that this comment was about skipping an element from
jsonb in order to change/delete it,
not about the last
> If the patch were proposing a similar amount of new infrastructure to
> support some datatype-extensible concept of subscripting, I'd be much
> happier about it.
Well, actually, I agree with that. I can try to rework the patch to achieve
this goal.
On 1 March 2016 at 06:34, Michael Paquier wrote:
> On Mon, Feb 29, 2016 at 8:43 PM, Valery Popov
> wrote:
> > vpopov@vpopov-Ubuntu:~/Projects/pwdtest/postgresql$ git branch
>
> Thanks for the input!
>
> > 0001-Add-facility-to-store-multiple-password-verifiers.patch:2547:
> trailing
> > whitespac
> I'd strongly prefer the jsonb_array_insert naming though
> I don't think it's a good idea to use set when this is used on object, I
think that we should throw error in that case.
Well, I thought it's wrong to introduce different functions and behaviour
patterns for objects and arrays, because it
Hi
As far as I see there is one basic update function for jsonb, that can't be
covered by `jsonb_set` - insert a new value into an array at arbitrary
position.
Using `jsonb_set` function we can only append into array at the end/at the
beginning, and it looks more like a hack:
```
=# select jsonb_
On 20 January 2016 at 02:14, Alvaro Herrera
wrote:
> Dmitry Dolgov wrote:
>
> > I've cleaned up the code, created a separate JsonbRef node (and there
> are a
> > lot of small changes because of that), abandoned an idea of "deep
> nesting"
> > of as
Hi,
Here is a reworked version of patch for jsonb subscription.
There weren't many changes in functionality:
=# create TEMP TABLE test_jsonb_subscript (
id int,
test_json jsonb
);
=# insert into test_jsonb_subscript values
(1, '{}'),
(2, '{}');
=# update test_jsonb_subscript set t
> if there's any future intention to add a delete operator that removes
element/pair matches?
I think the operator (jsonb - jsonb) is logical because we have a shallow
concatenation function (something like a "union" operation), but we have
nothing like "set difference" and "intersection" functio
>> For that matter, we should probably disallow NULL path elements also,
shouldn't we?
> I'd say yes.
Well, here is the new `setPath` function with this modification. Is it what
did you mean?
non_integer_in_path2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hack
postgres=# SELECT jsonb_set(
'{"name": "Joe", "vehicle_types": ["car", "van"]}'::jsonb,
'{vehicle_types, nonsense}',
'"motorcycle"', true);
ERROR: path element at the position 2 is not an integer
I'm sorry, but I'm not sure, what behavior is expected in this case?
Right now the following logic was implemented:
"we trying to set an element inside an array, but we've got a
non-integer path item
("nonsense" in this particular case), so we're going to add a new
element at the end of arr
Hi,
Some time ago the array-style subscripting for the jsonb data type was
discussed in this mailing list. I think it will be quite convenient to have
a such nice syntax to update jsonb objects, so I'm trying to implement
this. I created a patch, that allows doing something like this:
=# create
> creates the specified path if it does not exist. Does it?
No, jsonb_replace() doesn't create an element, if it doesn't exist. I
think, otherwise it can be confusing, so probably jsonb_add() may be more
appropriate (and, actually, this function was already mentioned in previous
discussions).
On
> Historical note: I think it's based on the nested hstore work, not on
current hstore, but Dmitry can answer on that.
Yes, you're right.
And I agree with thoughts above, that both concatenation modes ("simple"
and "deep") definitely can be useful. I can try to figure out how much work
that would
3 AM, Petr Jelinek wrote:
>>
>>> On 23/02/15 18:15, Dmitry Dolgov wrote:
>>>
>>>> Hi, Petr, thanks for the review.
>>>>
>>>> >>> I think it would be better if the ident printing didn't put the
> Frankly, I think the whole proposal needs to be rethought with an eye
towards supporting and preserving nested elements instead of trying to just
flatten everything out.
Can you pls show me few examples what do you mean exactly?
On 21 March 2015 at 06:51, Jim Nasby wrote:
> On 3/19/15 9:07 AM
--
> {"b": {"c": ["d", "f", {"g": 4}]}}
Yes, sure (the similar logic already implemented for the jsonb_concat).
On 20 March 2015 at 18:39, Thom Brown wrote:
> On 20 March 2015 at 11:21, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
ise and I didn't consider the implementation with path usage). If
this so confusing, I can remove this function from the list =)
On 20 March 2015 at 00:08, Alvaro Herrera wrote:
> Thom Brown wrote:
> > On 19 March 2015 at 14:35, Alvaro Herrera
> wrote:
> > > Thom Brown
[4, 5]}'::jsonb);
jsonb_intersection
--------
{"b": 2, "g": [4, 5]}
Schedule: I suppose, this can take 2-3 months for me. First of all I'll
implement the jsonb_delete_jsonb, jsonb_slice, jsonb_to_array, jsonb_keys,
js
Hi, everyone
I'm Dmitry Dolgov, a phd student at the KemSU, Russia. I would like to
submit a proposal to the GSoC about additional jsonb functionality, and I
want to get any feedback and thougths about this.
Hi, Thom.
> Would this support deleting "type" and the value 'dd'
With this patch you can delete them one by one:
select '{"a": 1, "b": 2, "c": {"type": "json", "stuff": "test"}, "d":
["aa","bb","cc","dd"]}'::jsonb - '{c, type}'::text[] - '{d, -1}'::text[];
?column?
Hi, Petr, thanks for the review.
>>> I think it would be better if the ident printing didn't put the start
of array ([) and start of dictionary ({) on separate line
Did you mean this?
[
{
"a": 1,
"b": 2
}
]
I tried to verify this in several ways (h
I would like to participate as student.
On 10 February 2015 at 03:52, Thom Brown wrote:
> Hi all,
>
> Google Summer of Code 2015 is approaching. I'm intending on registering
> PostgreSQL again this year.
>
> Before I do that, I'd like to have an idea of how many people are
> interested in being
Hi all,
I'm faced with some troubles about the jsonb implementation, and I hope
I'll get little advice =)
If I understand correctly, an abstract function for jsonb modification
should have the following stages:
Jsonb -> JsonbValue -> Modification -> JsonbValue -> Jsonb
One can convert the *Jsonb
Hi all,
I'm little confused by the *convertJsonbValue* functon at *jsonb_utils.c*
Maybe I misunderstood something, so I need help =)
>>> if (IsAJsonbScalar(val) || val->type == jbvBinary)
>>> convertJsonbScalar(buffer, header, val);
As I can see, the *convertJsonbScalar* function is used for
:11, Josh Berkus wrote:
> On 04/24/2014 03:46 AM, Dmitry Dolgov wrote:
> > Hi all,
> >
> > As you know, PostgreSQL introduced Json(b) support at the 9.4 version
> [1],
> > and hstore v2.0 saved in separate repository [2]. But although PostgreSQL
> > has this sup
Hi all,
As you know, PostgreSQL introduced Json(b) support at the 9.4 version [1],
and hstore v2.0 saved in separate repository [2]. But although PostgreSQL
has this support at the core level, there are many useful functions, which
wasn't ported to Json(b) from hstore v2.0 and json. Here [3], I've
82 matches
Mail list logo
