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:
On Sat, Oct 5, 2013 at 6:15 PM, Marko Tiikkaja ma...@joh.to 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
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
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 discussion
On Fri, Oct 4, 2013 at 3:53 AM, Marko Tiikkaja ma...@joh.to 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
On Sat, Sep 28, 2013 at 8:42 AM, Marko Tiikkaja ma...@joh.to 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
Hi
Sorry for the delay on following up on this.
2013/9/18 Marko Tiikkaja ma...@joh.to:
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
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
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.
2013/9/15 Marko Tiikkaja ma...@joh.to:
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 [*],
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
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
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
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
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
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 option to
me. Any
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
18 matches
Mail list logo
