On 24 March 2014 10:58, Petr Jelinek wrote:
> Docs updated.
OK, it looks to me that all outstanding comments have been resolved.
I'll be looking to commit this later today, so last call for comments.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
On 23/03/14 19:38, Pavel Stehule wrote:
doc should be enhanced by:
Docs updated.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index bddd458..2a9b3
2014-03-23 15:53 GMT+01:00 Petr Jelinek :
>
>
> On 23/03/14 15:14, Pavel Stehule wrote:
>
>> Review shadow_v6 patch
>>
>>
>> I have only one objection - What I remember - more usual is using a list
>> instead a bitmap for these purposes - typical is DefElem struct. Isn't
>> it better?
>>
>>
> To m
On 23/03/14 15:14, Pavel Stehule wrote:
Review shadow_v6 patch
I have only one objection - What I remember - more usual is using a list
instead a bitmap for these purposes - typical is DefElem struct. Isn't
it better?
To me it seemed that for similar use cases (list of boolean options) the
2014-03-23 15:14 GMT+01:00 Pavel Stehule :
> Review shadow_v6 patch
>
> Hello
>
> I did a recheck a newest version of this patch:
>
> 1. There is a wide agreement on implemented feature - nothing changed from
> previous review - it is not necessary comment it again.
>
> 2. v6 patch: patching clean
Review shadow_v6 patch
Hello
I did a recheck a newest version of this patch:
1. There is a wide agreement on implemented feature - nothing changed from
previous review - it is not necessary comment it again.
2. v6 patch: patching cleanly, compilation without errors and warnings, all
regress tes
On 03/22/2014 04:00 PM, Tom Lane wrote:
On the other side, coding with the explicit cast helps guard against far
more dangerous coding errors, which the compiler will*not* help you with.
What if myextra is actually of type "int64 *"?
Indeed, neither "gcc -Wall -Wextra -std=c89 -pedantic" nor "cl
Piotr Stefaniak writes:
> Apart from what the page says, I also think of casting malloc() as bad
> style and felt the need to bring this up.
Well, that's a value judgement I don't happen to agree with. Yeah, it'd
be better if the language design were such that we could avoid explicit
casting ev
On 03/22/2014 04:00 PM, Tom Lane wrote:
That argument is entirely bogus, as it considers only one possible way
in which the call could be wrong; a way that is of very low probability
in PG usage, since we include in our core headers. Besides
which, as noted in the page itself, most modern compi
Piotr Stefaniak writes:
>>> +myextra = (int *) malloc(sizeof(int));
> Please consider not casting malloc(). See
That code is per project style, and should stay that way.
> http://c-faq.com/malloc/mallocnocast.html
That argument is entirely bogus, as it considers only one possible way
in w
> +myextra = (int *) malloc(sizeof(int));
Please consider not casting malloc(). See
http://c-faq.com/malloc/mallocnocast.html
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Marko Tiikkaja writes:
> On 3/20/14, 12:32 AM, Tom Lane wrote:
>> Also, adding GUC_LIST_INPUT later is not really cool since it changes
>> the parsing behavior for the GUC. If it's going to be a list, it should
>> be one from day zero.
> I'm not sure what exactly you mean by this. If the only a
On 20/03/14 00:32, Tom Lane wrote:
TBH, if I thought this specific warning was the only one that would ever
be there, I'd probably be arguing to reject this patch altogether.
Of course, nobody assumes that it will be the only one.
Also, adding GUC_LIST_INPUT later is not really cool since i
On 3/20/14, 12:32 AM, Tom Lane wrote:
Isn't the entire point to create a framework in which more tests will
be added later?
Also, adding GUC_LIST_INPUT later is not really cool since it changes
the parsing behavior for the GUC. If it's going to be a list, it should
be one from day zero.
I'm n
2014-03-20 0:32 GMT+01:00 Tom Lane :
> Petr Jelinek writes:
> > On 19/03/14 19:26, Alvaro Herrera wrote:
> >> I think this should have the GUC_LIST_INPUT flag, and ensure that when
> >> multiple values are passed, we can process them all in a sane fashion.
>
> > Well, as we said with Marko in the
Petr Jelinek writes:
> On 19/03/14 19:26, Alvaro Herrera wrote:
>> I think this should have the GUC_LIST_INPUT flag, and ensure that when
>> multiple values are passed, we can process them all in a sane fashion.
> Well, as we said with Marko in the original thread, the proper handling
> is left
On 19/03/14 19:26, Alvaro Herrera wrote:
Petr Jelinek escribió:
+
+ These additional checks are enabled through the configuration variables
+ plpgsql.extra_warnings for warnings and
+ plpgsql.extra_errors for errors. Both can be set either to
+ a comma-separated list of checks, "none" or
Petr Jelinek escribió:
> +
> + These additional checks are enabled through the configuration variables
> + plpgsql.extra_warnings for warnings and
> + plpgsql.extra_errors for errors. Both can be set either to
> + a comma-separated list of checks, "none" or "all".
> + The default is "none".
2014-03-19 13:51 GMT+01:00 Alvaro Herrera :
> Why start a new thread for this review? It seems to me it'd be more
> comfortable to keep the review as a reply on the original thread.
>
I am sorry, I though so review should to start in separate thread
Pavel
>
> --
> Álvaro Herrera
Why start a new thread for this review? It seems to me it'd be more
comfortable to keep the review as a reply on the original thread.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (
Hello
all is pk
Pavel
2014-03-19 11:28 GMT+01:00 Petr Jelinek :
>
> On 19/03/14 09:45, Pavel Stehule wrote:
>
>> Hello
>>
>> This patch introduce a possibility to implement some new checks without
>> impact to current code.
>>
>> 1. there is a common agreement about this functionality, syntax,
On 19/03/14 09:45, Pavel Stehule wrote:
Hello
This patch introduce a possibility to implement some new checks without
impact to current code.
1. there is a common agreement about this functionality, syntax, naming
2. patching is clean, compilation is without error and warning
3. all regress
Hello
This patch introduce a possibility to implement some new checks without
impact to current code.
1. there is a common agreement about this functionality, syntax, naming
2. patching is clean, compilation is without error and warning
3. all regress tests passed
4. feature is well documented
23 matches
Mail list logo
