On 10/7/13 9:46 PM, Robert Haas wrote:
Looks good to me. Committed.
Thanks.
Also huge thanks to Ian for a phenomenal first review. :-)
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
On Sat, Oct 5, 2013 at 6:15 PM, Marko Tiikkaja wrote:
> Something like the attached?
Looks good to me. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 04/10/2013 16:08, Robert Haas wrote:
Yeah, that doesn't seem good. How about writing the grammar production as
'#' K_PRINT_STRICT_PARAMS option_value
where option_value := T_WORD | unreserved_keyword;
Then you don't need to make ON and OFF keywords; you can just use
strcmp() against the o
On Fri, Oct 4, 2013 at 3:53 AM, Marko Tiikkaja wrote:
> I don't think there has.
>
> I originally had more ideas for options which you could turn on/off, which I
> believe might have justified reserving them, but I'm not sure any of those
> will ever happen, at least not as a simple on/off option.
On 10/3/13 6:55 PM, Robert Haas wrote:
This looks like a nice clean patch. My only concern is that it makes
"on" and "off" unreserved plpgsql keywords. It looks like that will
make them unusable as unquoted identifiers in a few contexts in which
they can now be used. Has there been any discuss
On Sat, Sep 28, 2013 at 8:42 AM, Marko Tiikkaja wrote:
> On 2013-09-28 12:31, Ian Lawrence Barwick wrote:
>> The patch looks good to me now; does the status need to be changed to
>> "Ready for Committer"?
>
> Yes.
>
> Thanks for reviewing!
This looks like a nice clean patch. My only concern is t
On 2013-09-28 12:31, Ian Lawrence Barwick wrote:
The patch looks good to me now; does the status need to be changed to
"Ready for Committer"?
Yes.
Thanks for reviewing!
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Hi
Sorry for the delay on following up on this.
2013/9/18 Marko Tiikkaja :
> Hi,
>
> Attached is a patch with the following changes:
>
> On 16/09/2013 10:57, I wrote:
>>
>> On 9/16/13 8:04 AM, Ian Lawrence Barwick wrote:
>>>
>>> However the sample function provided in the documentation throws a
>
Hi,
Attached is a patch with the following changes:
On 16/09/2013 10:57, I wrote:
On 9/16/13 8:04 AM, Ian Lawrence Barwick wrote:
However the sample function provided in the documentation throws a
runtime error due to a missing FROM-clause entry.
Ugh. I'll look into fixing that.
Fixed.
On 9/16/13 8:04 AM, Ian Lawrence Barwick wrote:
I'm taking a look at this patch as part of the current commitfest [*],
Thanks!
However the sample function provided in the documentation throws a
runtime error due to a missing FROM-clause entry.
Ugh. I'll look into fixing that.
* Does it f
2013/9/15 Marko Tiikkaja :
>
> Attached an updated patch to fix the tabs and to change this to a
> compile-time option. Now it's not possible to flexibly disable the feature
> during runtime, but I think that's fine.
I'm taking a look at this patch as part of the current commitfest [*],
(It's the
On 15/09/2013 04:02, Peter Eisentraut wrote:
On Fri, 2013-09-13 at 23:56 +0200, Marko Tiikkaja wrote:
Attached is a patch for optionally printing more information on STRICT
failures in PL/PgSQL:
Please fix the tabs in the SGML files.
Oops. Thanks.
Attached an updated patch to fix the tabs
On Fri, 2013-09-13 at 23:56 +0200, Marko Tiikkaja wrote:
> Attached is a patch for optionally printing more information on STRICT
> failures in PL/PgSQL:
Please fix the tabs in the SGML files.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On 2013-09-14 03:33, Alvaro Herrera wrote:
Marko Tiikkaja wrote:
I thought about that, but it seemed more like a runtime option to
me. Any particular reason you think it would be better as a compile
time option?
Seems like something that would be useful to change per function, rather
than glob
Marko Tiikkaja wrote:
> On 2013-09-14 00:39, Alvaro Herrera wrote:
> >>set plpgsql.print_strict_params to true;
> >
> >Hmm, shouldn't this be a compile option? See the "comp_option"
> >production in pl_gram.y for existing examples.
>
> I thought about that, but it seemed more like a runtime optio
On 2013-09-14 00:39, Alvaro Herrera wrote:
set plpgsql.print_strict_params to true;
Hmm, shouldn't this be a compile option? See the "comp_option"
production in pl_gram.y for existing examples.
I thought about that, but it seemed more like a runtime option to me.
Any particular reason you t
Marko Tiikkaja wrote:
> set plpgsql.print_strict_params to true;
Hmm, shouldn't this be a compile option? See the "comp_option"
production in pl_gram.y for existing examples.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hi,
Attached is a patch for optionally printing more information on STRICT
failures in PL/PgSQL:
set plpgsql.print_strict_params to true;
create or replace function footest() returns void as $$
declare
x record;
p1 int := 2;
p3 text := 'foo';
begin
-- too many rows
select * from foo wher
18 matches
Mail list logo