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.
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
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 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:
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
+++
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
"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
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
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
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:
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
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
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
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
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
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
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
> > >>
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.
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
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
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
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
+++
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.
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
2017-05-19 5:48 GMT+02:00 Pavel Stehule :
>
>
> 2017-05-19 3:14 GMT+02:00 Peter Eisentraut com>:
>
>> On 5/15/17 14:34, Pavel Stehule wrote:
>> > Now, I when I working on plpgsql_check, I have to check function
>> > parameters. I
29 matches
Mail list logo