ne 7. 2. 2021 v 19:18 odesílatel Zhihong Yu napsal:
> Hi,
>
> bq. SELECT unnest('[[5,2],"a",[8,[3,2],6]]'::jsonb);
>
> Since the array without cast is not normal array (and would be rejected),
> I wonder if the cast is needed.
> Because casting to jsonb is the only legitimate interpretation
On Sunday, February 7, 2021, Zhihong Yu wrote:
> Hi,
> # SELECT '[[5,2],"a",[8,[3,2],6]]'::jsonb;
> jsonb
> ---
> [[5, 2], "a", [8, [3, 2], 6]]
> (1 row)
>
> unnest(array[[3,2],"a",[1,4]]) is not accepted currently.
>
> Would the enhanced unnest accept
ne 7. 2. 2021 v 18:43 odesílatel Joel Jacobson napsal:
> On Sun, Feb 7, 2021, at 18:33, Zhihong Yu wrote:
> >Hi,
> ># SELECT '[[5,2],"a",[8,[3,2],6]]'::jsonb;
> > jsonb
> >---
> > [[5, 2], "a", [8, [3, 2], 6]]
> >(1 row)
> >
>
Hi,
bq. SELECT unnest('[[5,2],"a",[8,[3,2],6]]'::jsonb);
Since the array without cast is not normal array (and would be rejected), I
wonder if the cast is needed.
Because casting to jsonb is the only legitimate interpretation here.
Cheers
On Sun, Feb 7, 2021 at 9:42 AM Joel Jacobson wrote:
>
Here is a more polished version of the function pointer approach, now
adapted to all multibyte encodings. Using the not-yet-committed tests from
[1], I found a thinko bug that resulted in the test for nul bytes to not
only be wrong, but probably also elided by the compiler. Doing it correctly
is
[Found it :-)]
On 2021-Feb-05, Mark Rofail wrote:
> We will focus on getting the operator patch through first. Should I create
> a separate commitfest ticket? or the current one suffices?
> https://commitfest.postgresql.org/32/2966/
I think the current one is fine. In fact I would encourage
Having thought about this some more,
the function name should of course be jsonb_unnest(),
similar to how unnest() works for normal arrays:
SELECT unnest(array[[3,2],[1,4]]);
unnest
3
2
1
4
(4 rows)
SELECT jsonb_unnest('[[3,2],[1,4]]'::jsonb);
jsonb_unnest
Hi,
For index_has_deprecated_collation(),
+ object.objectSubId = 0;
The objectSubId field is not accessed
by do_check_index_has_deprecated_collation(). Does it need to be assigned ?
For RelationGetIndexListFiltered(), it seems when (options &
REINDEXOPT_COLL_NOT_CURRENT) == 0, the full_list
Hi
fresh rebase
Regards
Pavel
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index b4c70aaa7f..1bafd202ff 100644
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -4093,6 +4093,8 @@ plpgsql_estate_setup(PLpgSQL_execstate *estate,
{
Hi Massimo,
Thanks for the interest, and my apologies for the late reply.
I’m not particularly abandoning it, but I don’t have particular reason to make
further changes at the moment. Far as I’m concerned it works, and the main
question is whether it is acceptable and useful.
I’d be happy if
Bruce Momjian writes:
> On Sun, Feb 7, 2021 at 11:21:05AM +0100, Magnus Hagander wrote:
>> Isn't the whole "Success." at the end redundant here, and we should
>> just end the message after the pg_ctl command? So not just the extra
>> newline, but the whole thing?
> Agreed.
+1
Hi
ne 7. 2. 2021 v 16:59 odesílatel Joel Jacobson napsal:
> Having thought about this some more,
> the function name should of course be jsonb_unnest(),
> similar to how unnest() works for normal arrays:
>
> SELECT unnest(array[[3,2],[1,4]]);
> unnest
>
> 3
> 2
> 1
>
Hi,
# SELECT '[[5,2],"a",[8,[3,2],6]]'::jsonb;
jsonb
---
[[5, 2], "a", [8, [3, 2], 6]]
(1 row)
unnest(array[[3,2],"a",[1,4]]) is not accepted currently.
Would the enhanced unnest accept the above array ?
Cheers
On Sun, Feb 7, 2021 at 8:31 AM Joel
On Fri, Feb 5, 2021 at 07:53:18PM -0500, Bruce Momjian wrote:
> On Fri, Feb 5, 2021 at 05:21:22PM -0500, Stephen Frost wrote:
> > > I disagree. If we only warn about some parts, attackers will just
> > > attack other parts. It will also give users a false sense of security.
> > > If you can
On Sun, Feb 7, 2021, at 17:08, Pavel Stehule wrote:
>>ne 7. 2. 2021 v 16:59 odesílatel Joel Jacobson napsal:
>>
>>SELECT jsonb_unnest('[[3,2],[1,4]]'::jsonb);
>>jsonb_unnest
>>
>>3
>>2
>>1
>>4
>>(4 rows)
>
>It has sense. Maybe it should return two columns - first path to
"Joel Jacobson" writes:
> Having thought about this some more,
> the function name should of course be jsonb_unnest(),
> similar to how unnest() works for normal arrays:
Why not just unnest(), then?
regards, tom lane
Greg Nancarrow writes:
> On Sun, Feb 7, 2021 at 10:03 AM Tom Lane wrote:
>> I think either the bit about rule_action is unnecessary, or most of
>> the code immediately above this is wrong, because it's only updating
>> flags in sub_action. Why do you think it's necessary to change
>>
On Sun, Feb 7, 2021, at 18:42, Joel Jacobson wrote:
>SELECT pit.jsonb_array_elements_recursive(value);
Sorry, that line should have been:
SELECT unnest(value);
I wrote:
> That semantic issue doesn't get any less pressing just because the query
> was generated by rewrite. So I now think that what we have to do is
> throw an error if we have a modifying CTE and sub_action is different
> from rule_action. Not quite sure how to phrase the error though.
On 2021-Feb-07, Mark Rofail wrote:
> Changelog (operator patch):
> > - v1 (compatible with current master 2021-02-05,
> > commit c72af5c202067a9ecb0ff8df7370fb1ea8f4)
> > * add tests and documentation to array operators and gin index
> >
> Since we agreed to separate @>> and <<@ operators
On Sun, Feb 7, 2021, at 17:27, Tom Lane wrote:
>"Joel Jacobson" writes:
>> Having thought about this some more,
>> the function name should of course be jsonb_unnest(),
>> similar to how unnest() works for normal arrays:
>
>Why not just unnest(), then?
>
>regards, tom lane
Ahh, of course! I
On Sun, Feb 7, 2021, at 18:33, Zhihong Yu wrote:
>Hi,
># SELECT '[[5,2],"a",[8,[3,2],6]]'::jsonb;
> jsonb
>---
> [[5, 2], "a", [8, [3, 2], 6]]
>(1 row)
>
>unnest(array[[3,2],"a",[1,4]]) is not accepted currently.
>
>Would the enhanced unnest accept the above
"Tang, Haiying" writes:
> When using psql I found there's no tab completion for upper character inputs.
> It's really inconvenient sometimes so I try to fix this problem in the
> attached patch.
This looks like you're trying to force case-insensitive behavior
whether that is appropriate or
On Sat, Feb 6, 2021 at 7:41 PM Peter Geoghegan wrote:
> Yes, please do. I could do it myself, but better that you do it
> yourself, just in case.
I went ahead and fixed it myself.
Thanks
--
Peter Geoghegan
Hi
ne 7. 2. 2021 v 18:31 odesílatel Zhihong Yu napsal:
> Hi,
> # SELECT '[[5,2],"a",[8,[3,2],6]]'::jsonb;
> jsonb
> ---
> [[5, 2], "a", [8, [3, 2], 6]]
> (1 row)
>
> unnest(array[[3,2],"a",[1,4]]) is not accepted currently.
>
> Would the enhanced unnest
On Sun, Feb 7, 2021 at 11:39 AM Pavel Stehule
wrote:
>
>
> ne 7. 2. 2021 v 19:18 odesílatel Zhihong Yu napsal:
>
>> Hi,
>>
>> bq. SELECT unnest('[[5,2],"a",[8,[3,2],6]]'::jsonb);
>>
>> Since the array without cast is not normal array (and would be rejected),
>> I wonder if the cast is needed.
[ redirecting to -hackers ]
Alexander Korotkov writes:
>> BTW, I managed to reproduce the issue by compiling with CFLAGS="-O0
>> -fsanitize=alignment -fsanitize-trap=alignment" and the patch
>> attached.
>> I can propose the following to catch such issues earlier. We could
>> finish (wrap
Hi,
On Sun, 7 Feb 2021 19:27:02 +0530
Dilip Kumar wrote:
> On Sun, Feb 7, 2021 at 6:44 PM Bharath Rupireddy
> wrote:
> >
> > On Fri, Feb 5, 2021 at 10:14 AM Bharath Rupireddy
> > wrote:
> > > > We can not do that, basically, under one lock we need to check the
> > > > state and set it to
Dear Horiguchi-san,
My response crossed in the e-mail with yours. Sorry.
> FWIW, directly embedding /unixsocket/path syntax in a URL is broken in
> the view of URI. It is the reason why the current connection URI takes
> the way shown above. So I think we want to remove that code rather
> than
> Posting an updated set of patches.
A minor comment about doc.
+
+Where the above target table features are determined to be, at worst,
+parallel-restricted, rather than parallel-unsafe, at least a parallel table
+scan may be used in the query plan for the INSERT
+statement.
On 2021/02/05 8:45, Masahiro Ikeda wrote:
I pgindented the patches.
Thanks for updating the patches!
+ XLogWrite, which nomally called by an
+ issue_xlog_fsync, which nomally called by an
Typo: "nomally" should be "normally"?
+ XLogFlush request(see )
+ XLogFlush
On Mon, 8 Feb 2021 09:35:00 +0530
Dilip Kumar wrote:
> On Mon, Feb 8, 2021 at 8:18 AM Yugo NAGATA wrote:
> >
> > On Mon, 8 Feb 2021 07:51:22 +0530
> > Dilip Kumar wrote:
> >
> > > On Mon, 8 Feb 2021 at 6:38 AM, Yugo NAGATA wrote:
> > >
> > > > Hi,
> > > >
> > > > On Sun, 7 Feb 2021 19:27:02
On Monday, February 8, 2021 1:44 PM osumi.takami...@fujitsu.com
> On Mon, Feb 8, 2021 12:40 PM Amit Kapila
> wrote:
> > On Mon, Feb 8, 2021 at 8:06 AM Peter Smith
> > wrote:
> > >
> > > On Sat, Feb 6, 2021 at 6:30 PM osumi.takami...@fujitsu.com
> > > wrote:
> > > >
> > > > > I have another
On Mon, Feb 1, 2021 at 7:20 PM Tang, Haiying wrote:
>
> Hi Greg,
>
> Recently, I was keeping evaluating performance of this patch(1/28 V13).
> Here I find a regression test case which is parallel insert with bitmap heap
> scan.
> when the target table has primary key or index, then the patched
On Sat, Feb 6, 2021 at 6:30 PM osumi.takami...@fujitsu.com
wrote:
>
> Hi
>
>
> On Friday, February 5, 2021 5:51 PM Amit Kapila
> wrote:
> > On Fri, Feb 5, 2021 at 12:36 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > We need to add some tests to prove the new checks of
On Mon, 8 Feb 2021 07:51:22 +0530
Dilip Kumar wrote:
> On Mon, 8 Feb 2021 at 6:38 AM, Yugo NAGATA wrote:
>
> > Hi,
> >
> > On Sun, 7 Feb 2021 19:27:02 +0530
> > Dilip Kumar wrote:
> >
> > > On Sun, Feb 7, 2021 at 6:44 PM Bharath Rupireddy
> > > wrote:
> > > >
> > > > On Fri, Feb 5, 2021 at
Hello
On Mon, Feb 8, 2021 12:40 PM Amit Kapila wrote:
> On Mon, Feb 8, 2021 at 8:06 AM Peter Smith
> wrote:
> >
> > On Sat, Feb 6, 2021 at 6:30 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > > I have another idea for a test case: What if we write a test such
> > > > that it fails PK
Dear Wang,
> the value tmp2 will always be NULL, the unix-socket path will be ignored.
I confirmed it, you're right.
> I have fixed this problem, the patch attached.
It looks good to me:-).
> I will try to fix this problem later, but it seems a little difficult to add
> some lex/bison file
On Sun, Feb 7, 2021 at 2:38 PM Peter Smith wrote:
>
> On Sat, Feb 6, 2021 at 2:10 AM Petr Jelinek
> wrote:
> >
> > Hi,
> >
> > Some minor comments about code:
> >
> > > + else if (res->status == WALRCV_ERROR && missing_ok)
> > > + {
> > > + /* WARNING.
I wrote:
> * Both clang and gcc seem to be happy with the same spelling of the
> function attribute, which is fortunate. However, I seriously doubt
> that bare "#ifdef __GNUC__" is going to be good enough. At the very
> least there's going to need to be a compiler version test in there,
> and we
On Mon, Feb 8, 2021 at 8:06 AM Peter Smith wrote:
>
> On Sat, Feb 6, 2021 at 6:30 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > > I have another idea for a test case: What if we write a test such that it
> > > fails PK
> > > violation on copy and then drop the subscription. Then check there
On Mon, Feb 8, 2021 at 8:18 AM Yugo NAGATA wrote:
>
> On Mon, 8 Feb 2021 07:51:22 +0530
> Dilip Kumar wrote:
>
> > On Mon, 8 Feb 2021 at 6:38 AM, Yugo NAGATA wrote:
> >
> > > Hi,
> > >
> > > On Sun, 7 Feb 2021 19:27:02 +0530
> > > Dilip Kumar wrote:
> > >
> > > > On Sun, Feb 7, 2021 at 6:44 PM
On 2021/02/08 13:01, Fujii Masao wrote:
On 2021/02/05 8:45, Masahiro Ikeda wrote:
I pgindented the patches.
Thanks for updating the patches!
+ XLogWrite, which nomally called by an
+ issue_xlog_fsync, which nomally called by an
Typo: "nomally" should be "normally"?
+
On Mon, Feb 8, 2021 at 9:35 AM Dilip Kumar wrote:
> > > > If a user call pg_wal_replay_pause while waiting in
> > > > RecoveryRequiresIntParameter,
> > > > the state become 'pause requested' and this never returns to 'paused'.
> > > > Should we check recoveryPauseState in this loop as in
> > >
>
On 2021-02-04 11:19, Kyotaro Horiguchi wrote:
At Thu, 04 Feb 2021 10:16:47 +0900, torikoshia
wrote in
Chengxi Sun, Yamada-san, Horiguchi-san,
Thanks for all your comments.
Adding only the number of generic plan execution seems acceptable.
On Mon, Jan 25, 2021 at 2:10 PM Kyotaro Horiguchi
On Sat, Feb 6, 2021 at 5:47 PM Amit Kapila wrote:
>
> On Sat, Feb 6, 2021 at 3:26 PM Petr Jelinek wrote:
> >
> > On 06/02/2021 07:29, Amit Kapila wrote:
> > > On Fri, Feb 5, 2021 at 6:45 PM Euler Taveira wrote:
> > >> - replorigin_drop(roident, true);
> > >> + replorigin_drop_by_name(name,
On Fri, Jan 29, 2021 at 06:43:44PM +, Bossart, Nathan wrote:
> I changed it to PROCESS_TOAST.
Thanks. PROCESS_TOAST sounds good to me at the end for the option
name, so let's just go with that.
> Done.
While on it, I could not resist with changing VACOPT_SKIPTOAST to
VACOPT_PROCESS_TOAST
On Mon, Jan 25, 2021 at 10:21 AM Andy Fan wrote:
>
>
> On Sun, Jan 24, 2021 at 6:34 PM Andy Fan wrote:
>
>> Hi:
>>
>> I recently found a use case like this. SELECT * FROM p, q WHERE
>> p.partkey =
>> q.colx AND (q.colx = $1 OR q.colx = $2); Then we can't do either
>> planning time
>>
On Mon, 8 Feb 2021 at 6:38 AM, Yugo NAGATA wrote:
> Hi,
>
> On Sun, 7 Feb 2021 19:27:02 +0530
> Dilip Kumar wrote:
>
> > On Sun, Feb 7, 2021 at 6:44 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Fri, Feb 5, 2021 at 10:14 AM Bharath Rupireddy
> > > wrote:
> > > > > We can not do that,
At Thu, 4 Feb 2021 09:25:00 +, "Wang, Shenhao"
wrote in
> Hi, hacker
>
> I found in function ECPGconnect, the connect string in comment is written as:
>
> /*--
> * new style:
> *:postgresql://server[:port|:/unixsocket/path:]
> *[/db-name][?options]
> *--
> */
>
> But,
On Mon, Feb 8, 2021 at 9:49 AM Bharath Rupireddy
wrote:
>
> On Mon, Feb 8, 2021 at 9:35 AM Dilip Kumar wrote:
> > > > > If a user call pg_wal_replay_pause while waiting in
> > > > > RecoveryRequiresIntParameter,
> > > > > the state become 'pause requested' and this never returns to 'paused'.
> >
On Wed, Feb 3, 2021 at 4:21 PM Peter Eisentraut
wrote:
>
> On 2021-01-17 14:38, Magnus Hagander wrote:
> > On Thu, Jan 7, 2021 at 11:53 AM Peter Eisentraut
> > wrote:
> >>
> >> After pondering this again, I think we can go with initdb
> >> --no-instructions, as in your patch.
> >>
> >> As a
Hi,
A particular useful feature of jsonb arrays,
is the ability to represent multidimensional arrays without matching dimensions,
which is not possible with normal PostgreSQL arrays.
SELECT array[[5,2],1,[8,[3,2],6]];
ERROR: multidimensional arrays must have array expressions with matching
On Sun, Feb 7, 2021 at 10:03 AM Tom Lane wrote:
>
> Greg Nancarrow writes:
> > I found a bug in the query rewriter. If a query that has a modifying
> > CTE is re-written, the hasModifyingCTE flag is not getting set in the
> > re-written query.
>
> Ugh.
>
> > I've attached the patch with the
Thank you for your comment! :D
I have fixed it and attached the revised patch.
regards,
2021年2月7日(日) 2:08 Zhihong Yu :
> Hi,
> + if (strcmp(defel->defname, "truncatable") == 0)
> + server_truncatable = defGetBoolean(defel);
>
> Looks like we can break out of
On Fri, Feb 5, 2021 at 10:14 AM Bharath Rupireddy
wrote:
> > We can not do that, basically, under one lock we need to check the
> > state and set it to pause. Because by the time you release the lock
> > someone might set it to RECOVERY_NOT_PAUSED then you don't want to set
> > it to
On Sun, Feb 7, 2021 at 6:44 PM Bharath Rupireddy
wrote:
>
> On Fri, Feb 5, 2021 at 10:14 AM Bharath Rupireddy
> wrote:
> > > We can not do that, basically, under one lock we need to check the
> > > state and set it to pause. Because by the time you release the lock
> > > someone might set it to
On Sun, Feb 7, 2021 at 11:21:05AM +0100, Magnus Hagander wrote:
> > It appears that there is an extra blank line in the initdb output before
> > "Success" now.
>
> Oops, clearly it does.
>
> That said, the full output is:
>
> """
> Success. You can now start the database server using:
>
>
58 matches
Mail list logo
