Hello Pavel,
v6 patch applies cleanly; make check ok; code, comments, doc & tests ok;
various interactive tests I did ok.
Thanks for this useful little feature!
Let's see what committers think about it.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
On 2017-05-21 06:37, Erik Rijkers wrote:
On 2017-05-20 14:40, Michael Paquier wrote:
On Fri, May 19, 2017 at 3:01 PM, Masahiko Sawada
wrote:
Also, as Horiguchi-san pointed out earlier, walreceiver seems need
the
similar fix.
Actually, now that I look at it, ready_to_display should as well b
On 2017-05-21 03:00, Tom Lane wrote:
> I wrote:
>> Also, I found two places where an overlength comment line is simply busted
>> altogether --- notice that a character is missing at the split point:
>
> I found the cause of that: you need to apply this patch:
>
> --- freebsd_indent/pr_comment.c~
Hi
2017-04-02 21:57 GMT+02:00 Fabien COELHO :
>
> More to the point, we already have that. See c.h:
>>
>> #define CppAsString(identifier) #identifier
>> #define CppAsString2(x) CppAsString(x)
>>
>
> Thanks for the pointer. I grepped for them without success. Here is a v4.
I am
On 2017-05-20 14:40, Michael Paquier wrote:
On Fri, May 19, 2017 at 3:01 PM, Masahiko Sawada
wrote:
Also, as Horiguchi-san pointed out earlier, walreceiver seems need the
similar fix.
Actually, now that I look at it, ready_to_display should as well be
protected by the lock of the WAL receiver
On Sun, May 21, 2017 at 09:11:29AM +0530, Amit Kapila wrote:
> On Sun, May 21, 2017 at 5:26 AM, Bruce Momjian wrote:
> > On Fri, May 19, 2017 at 04:54:27PM -0400, Robert Haas wrote:
> >> On Tue, May 16, 2017 at 9:25 AM, Amit Kapila
> >> wrote:
> >> > On Tue, May 16, 2017 at 5:14 PM, Robert Haas
On Sun, May 21, 2017 at 5:26 AM, Bruce Momjian wrote:
> On Fri, May 19, 2017 at 04:54:27PM -0400, Robert Haas wrote:
>> On Tue, May 16, 2017 at 9:25 AM, Amit Kapila wrote:
>> > On Tue, May 16, 2017 at 5:14 PM, Robert Haas wrote:
>> >> On Tue, May 16, 2017 at 7:31 AM, Amit Kapila
>> >> wrote:
>
I wrote:
> Also, I found two places where an overlength comment line is simply busted
> altogether --- notice that a character is missing at the split point:
I found the cause of that: you need to apply this patch:
--- freebsd_indent/pr_comment.c~2017-05-17 14:59:31.548442801 -0400
+++ fr
On Fri, May 19, 2017 at 04:54:27PM -0400, Robert Haas wrote:
> On Tue, May 16, 2017 at 9:25 AM, Amit Kapila wrote:
> > On Tue, May 16, 2017 at 5:14 PM, Robert Haas wrote:
> >> On Tue, May 16, 2017 at 7:31 AM, Amit Kapila
> >> wrote:
> >>> I will send an updated patch once we agree on above poin
"MauMau" writes:
> Both pg_aggregate.aggfnoid and pg_trigger.tgfoid references
> pg_proc.oid, but the data types of them are regproc and oid
> respectively. Is there any criterion on when to which in the system
> catalog? Is the regproc choice just for readability of the catalog
> query output?
2017-05-20 22:26 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> - Maybe tests could also exercise unnamed columns, eg:
>>> SELECT 1, 2, 3 \gdesc \g
>>>
>>
>> done
>>
>
> Can't see it. No big deal, but if you put it it did not get through, and
> there is a warning with git apply on the very la
Hello,
Both pg_aggregate.aggfnoid and pg_trigger.tgfoid references
pg_proc.oid, but the data types of them are regproc and oid
respectively. Is there any criterion on when to which in the system
catalog? Is the regproc choice just for readability of the catalog
query output? Should pg_trigger.
Hello Pavel,
- Maybe tests could also exercise unnamed columns, eg:
SELECT 1, 2, 3 \gdesc \g
done
Can't see it. No big deal, but if you put it it did not get through, and
there is a warning with git apply on the very last line of the patch which
may be linked to that:
psql-gdesc-
David Rowley writes:
> I've been analyzing a reported regression case between a 9.5 plan and
> a 9.6 plan. I tracked this down to the foreign key join selectivity
> code, specifically the use_smallest_selectivity code which is applied
> to outer joins where the referenced table is on the outer sid
On Sat, May 20, 2017 at 11:26 AM, Cyril Auburtin
wrote:
> Ah sorry, first time, I thought it didn't pass
>
You should check our excellent online mailing list archives before
re-sending.
https://www.postgresql.org/list/
David J.
Ah sorry, first time, I thought it didn't pass
It's to support multiple ids (base64 ones are frequent) (or uuid's) in a
path. I think it's more practical than an array, for searching and sorting
But I understand that LTREE's main purpose is probably more for words
'breadcrumbs' etc..
2017-05-20
Hi
2017-05-20 9:15 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> I am sending a variant with message instead empty result.
>>
>
> Thanks. Patch looks good, applies, make check ok, code is neat.
>
> Personally I prefer empty result instead message.
>>
>
> Hmm. I think that this version is less li
The proximate cause of bug #14662,
https://www.postgresql.org/message-id/flat/20170519162316.29945.5021%40wrigleys.postgresql.org
appears to be that SplitIdentifierString's isspace() checks are
identifying some bytes of a multibyte character as spaces. It's not
quite clear to me whether there's an
Hi,
On 2017-05-20 21:19:10 +0900, Michael Paquier wrote:
> $subject has been raised in a recent thread here:
> https://www.postgresql.org/message-id/CAB7nPqTmym5t-X6hvMF_P-KRc=ndXtbQCTiU=nhs_jvl7x1...@mail.gmail.com
>
> The idea is to make the replication protocol a bit more flexible, in a
> way
On Sat, May 20, 2017 at 2:19 PM, Michael Paquier
wrote:
> Hi all,
>
> $subject has been raised in a recent thread here:
> https://www.postgresql.org/message-id/CAB7nPqTmym5t-
> X6hvMF_P-KRc=ndXtbQCTiU=nhs_jvl7x1...@mail.gmail.com
>
> The idea is to make the replication protocol a bit more flexibl
On Sat, May 20, 2017 at 1:27 AM, Cyril Auburtin
wrote:
> It could be useful to allow the `-` char in allowed LTREE label characters
> (currently
> a-zA-Z0-9_ https://www.postgresql.org/docs/9.6/static/ltree.html)
>
> The reason is to allow to use more easily base64 ids, (like
> https://github.c
On Fri, May 19, 2017 at 3:01 PM, Masahiko Sawada wrote:
> Also, as Horiguchi-san pointed out earlier, walreceiver seems need the
> similar fix.
Actually, now that I look at it, ready_to_display should as well be
protected by the lock of the WAL receiver, so it is incorrectly placed
in walreceiver
On Sat, Apr 15, 2017 at 02:30:18PM -0700, Andres Freund wrote:
> On 2017-04-15 17:24:54 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2017-04-15 17:09:38 -0400, Tom Lane wrote:
> > >> Why doesn't Windows' ability to map the segment into the new process
> > >> before it executes take ca
Hi all,
$subject has been raised in a recent thread here:
https://www.postgresql.org/message-id/CAB7nPqTmym5t-X6hvMF_P-KRc=ndXtbQCTiU=nhs_jvl7x1...@mail.gmail.com
The idea is to make the replication protocol a bit more flexible, in a
way similar to what 5c837dd has done, but for repl_scanner.l. T
On Wed, May 17, 2017 at 9:43 PM, Remi Colinet wrote:
>
> 2017-05-13 14:38 GMT+02:00 Amit Kapila :
>>
>> On Wed, May 10, 2017 at 10:10 PM, Remi Colinet
>> wrote:
>> >
>> > Parallel queries can also be monitored. The same mecanism is used to
>> > monitor
>> > child workers with a slight difference:
On Thu, May 18, 2017 at 7:56 PM, Robert Haas wrote:
> On Wed, May 17, 2017 at 6:57 AM, Amit Kapila wrote:
>> +1. Why not similar behavior for any other statements executed in
>> this module by do_sql_command?
>
> The other cases are not quite the same situation. It would be good to
> accept int
It could be useful to allow the `-` char in allowed LTREE label
characters (currently
a-zA-Z0-9_ https://www.postgresql.org/docs/9.6/static/ltree.html)
The reason is to allow to use more easily base64 ids, (like
https://github.com/dylang/shortid, ...), uuid's too in labels
`-` is also not used a
Hi
Now concat is 2x times slower than || operator. With cached FmgrInfo for
output function it will be only 5%.
Regards
Pavel
diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c
index be399f4..d3f04f8 100644
--- a/src/backend/utils/adt/varlena.c
+++ b/src/backend/utils
On 05/20/2017 05:41 AM, Tom Lane wrote:
Robert Haas writes:
I guess it does seem likely that most users of the hook would need to
do the same, but it seems confusing to pass the same function both x
and f(x), so my vote is to not do that.
Right, that was my thinking. (Except that my vote is t
Hello Pavel,
I am sending a variant with message instead empty result.
Thanks. Patch looks good, applies, make check ok, code is neat.
Personally I prefer empty result instead message.
Hmm. I think that this version is less likely to raise questions from
users, especially compared to hav
30 matches
Mail list logo
