overkill, though. I tried to keep things simple.
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 4712,4717 a_output := a_output || $$ if v_$$ || referrer_keys.kind ||
$$ like '$$
--- 4712,4762
/variablelist
/sect2
On 1/30/14, 10:44 AM, Erik Rijkers wrote:
This seems wrong: in HEAD, an empty select list does *not* generate a error
warning anymore:
This is intentional, see 1b4f7f93b4693858cb983af3cd557f6097dab67b
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers
.
- There are a few cases of curly braces around a single-statement
else, which I believe is against the project's code style guidelines.
Otherwise this patch looks good to my eyes.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Looks good to me.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that people weren't sure about, and people seemed to
think it should behave like this one does. So I've gone ahead and
committed this, crossing my fingers that we won't have to rip it back
out again.
Thanks! I'll keep my fingers crossed as well.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers
being.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/20/14 2:25 AM, Robert Haas wrote:
On Fri, Jan 17, 2014 at 5:45 AM, Marko Tiikkaja ma...@joh.to wrote:
I see these as being two are different things. There *is* a need for a
full-blown static analyzer for PL/PgSQL, but I don't think it needs to be in
core. However, there seems
On 1/20/14 1:55 PM, Robert Haas wrote:
On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja ma...@joh.to wrote:
What's so hard about plpgsql.warnings='all'? Or if the fact that it's a
list is your concern, I'm not going to oppose to making it a boolean.
Sure, that'd be fine. What I don't want
that? I'm not planning on fixing
the inconsistencies, though, despite them annoying me.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/19/14, 9:12 AM, Dean Rasheed wrote:
On 18 January 2014 03:07, Marko Tiikkaja ma...@joh.to wrote:
Here's the patch as promised. Thoughts?
A couple of points:
The answer for empty (zero dimensional) arrays is wrong --- you need
special case handling for this case to return 0.
How
this fixed for all functions, not just
array functions. But I think that should be a separate patch.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a pgindent run, I presume)? I just read
through three pagefuls and I didn't see any relevant changes, but I'm
not sure I want to keep doing that for the rest of the patch.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 1/18/14, 9:38 PM, Andrew Dunstan wrote:
On 01/18/2014 12:34 PM, Marko Tiikkaja wrote:
Is it possible for you to generate a diff that doesn't have all these
unrelated changes in it (from a pgindent run, I presume)? I just read
through three pagefuls and I didn't see any relevant changes
disk, the file my email clients claims to have sent
or a copy of the file I downloaded from the archives. Are you sure this
isn't a problem on your end?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
. However, there seems to be a number of pitfalls we could
warn the user about with little effort in core, and I think those are
worth doing.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
along these lines.
Here's the patch as promised. Thoughts?
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/array.sgml
--- b/doc/src/sgml/array.sgml
***
*** 338,343 SELECT array_length(schedule, 1) FROM sal_emp WHERE name =
'Carol';
--- 338,356
2
(1 row
.
Even I personally felt the Function and Volatility is nice to have info
into \do+.
Marking it as ready for committer.
Thanks for reviewing!
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 1/16/14 4:22 PM, Tom Lane wrote:
Marko Tiikkaja ma...@joh.to writes:
On 1/16/14 9:53 AM, Rushabh Lathia wrote:
Even I personally felt the Function and Volatility is nice to have info
into \do+.
FWIW, I'm on board with the idea of printing the oprcode, but adding
volatility here seems like
as well, sorry about
that. :-(
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
. That should probably be added? I'm not
sure when _PG_fini() would be called.
4) The comment /* reserved for use by optional plugin */ seems a bit
weird in its new context.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 1/15/14 7:07 AM, Florian Pflug wrote:
On Jan15, 2014, at 01:34 , Marko Tiikkaja ma...@joh.to wrote:
It's me again, trying to find a solution to the most common mistakes I make. This time
it's accidental shadowing of variables, especially input variables. I've wasted several
hours banging
On 1/15/14 11:20 AM, Pavel Stehule wrote:
2014/1/15 Marko Tiikkaja ma...@joh.to
Hmm. How about:
plpgsql.warnings = 'all' # enable all warnings, defauls to the empty
list, i.e. no warnings
plpgsql.warnings = 'shadow, unused' # enable just shadow and unused
warnings
On 1/15/14 11:33 AM, Pavel Stehule wrote:
2014/1/15 Marko Tiikkaja ma...@joh.to
I agree, it's better to include the word compiler in the GUC name. But
do we really need WARNING, ERROR and FATAL levels though? Would WARNING
and ERROR not be enough?
I am not strong in level names
accurately).
I like the idea of warning about SELECT .. INTO, though, but that one
could have a non-negligible performance penalty during execution.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 1/15/14 2:00 PM, Florian Pflug wrote:
On Jan15, 2014, at 13:32 , Marko Tiikkaja ma...@joh.to wrote:
On 1/15/14 1:23 PM, Florian Pflug wrote:
The fact that it's named plpgsql.warnings already clearly documents that this
only affects plpgsql. But whether a particular warning is emitted
On 1/15/14 2:27 PM, Pavel Stehule wrote:
2014/1/15 Marko Tiikkaja ma...@joh.to
Yeah, me neither, it's just something that needs to be communicated very
clearly. So probably just a list plpgsql.warnings would be the most
appropriate then.
I am thinking so the name is not good. Changing
. Every option shoudl to do one
clean thing.
It looks to me like the GUC *is* doing only one thing. list of
warnings I want to see, or the shorthand all for convenience.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
additional plpgsql extensions).
While this sounds cool, running a modified postgres locally seems a lot
easier. I already have to do that for PL/PgSQL development because of
the reasons I outlined in the thread PL/PgSQL, RAISE and error context.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers
INTO, then that solves
multiple problems in the language without breaking backwards
compatibility.
I don't personally have a problem with INTO other than the behaviour
that started this thread. But I'm willing to consider other options.
On Tue, Jan 14, 2014 at 4:30 AM, Marko Tiikkaja ma
Are you saying that DB2 supports the multi-variable assignment? I
couldn't find any reference suggesting that, can you point me to one?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On 1/14/14, 6:15 PM, Tom Lane wrote:
Marko Tiikkaja ma...@joh.to writes:
How about:
(a) = SELECT 1;
(a, b) = SELECT 1, 2;
(a, b) = INSERT INTO foo RETURNING col1, col2;
Same semantics: TOO_MANY_ROWS on rows 1, sets FOUND and row_count.
AFAICT this can be parsed unambiguously
change behaviour, just emits some warnings when a potentially faulty
function is compiled.
Let me know what you think so I can either cry or clean the patch up.
Regards,
Marko Tiikkaja
*** a/src/pl/plpgsql/src/pl_comp.c
--- b/src/pl/plpgsql/src/pl_comp.c
***
*** 352,357 do_compile
, we are going to have to do changes
like this to make the language better. Also I think that out of all the
things we could do to break backwards compatibility, this is closer to
harmless than a pain in the butt.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers
think I've ever publicly said that it should.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-01-14 02:54, Marti Raudsepp wrote:
On Sun, Jan 12, 2014 at 7:51 AM, Marko Tiikkaja ma...@joh.to wrote:
the behaviour of SELECT .. INTO when the query returns more than one row.
Some of you might know that no exception is raised in this case
Agreed. But I also agree with the rest
On 1/12/14, 7:47 AM, Pavel Stehule wrote:
2014/1/12 Marko Tiikkaja ma...@joh.to
Greetings fellow elephants,
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL:
the behaviour of SELECT .. INTO when
the API, can't we pass it
directly to the callback function? Am I missing something completely
obvious? :-)
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
state? If we're going to change the API, can't we pass it
directly to the callback function?
Oh, I think I'm being stupid -- we'd only have to do what *if* we don't
want to change the API? Then my vote is for breaking the API.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list
On 1/12/14, 10:19 PM, Florian Pflug wrote:
On Jan12, 2014, at 06:51 , Marko Tiikkaja ma...@joh.to wrote:
set plpgsql.consistent_into to true;
I don't think a GUC is the best way to handle this. Handling
this via a per-function setting similar to #variable_conflict would
IMHO be better
reasonable option. I'll
send an updated patch along these lines.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
as well. The patch, as currently written, also
changes the behaviour of EXECUTE .. INTO, but I don't feel strongly
about whether that should be affected as well or not.
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 1043,1050
On 1/10/14, 9:04 AM, Dean Rasheed wrote:
On 10 January 2014 00:36, Marko Tiikkaja ma...@joh.to wrote:
Can you point me to some examples?
The example I see all the time is code like
if array_length(nodes, 1) 5 then
... do something ...
then you realise (or not as the case may
}}'::int[]) would return VALUES (1,
'{1,2}'::int[]), (2, '{3,4}'::int[])? If so, then yes, that's a
functionality I've considered us to have been missing for a long time.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
with unnest()
without actually having to look at the length. Same goes for
multi-dimensional arrays: you have even less things you can do there
with only a length.
So if we give up these constraints, we also make this function
completely useless.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers
reasonable behaviors as possible.
That's exactly what I've done here. :-)
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
this to the next commit fest, but feel free to discuss it
before that.
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/array.sgml
--- b/doc/src/sgml/array.sgml
***
*** 338,343 SELECT array_length(schedule, 1) FROM sal_emp WHERE name =
'Carol';
--- 338,354
2
(1
On 2013-12-18 22:13, Andrew Dunstan wrote:
On 12/18/2013 03:27 PM, Marko Tiikkaja wrote:
Attached is a patch to add support for array_length(anyarray), which
only works for one-dimensional arrays, returns 0 for empty arrays and
complains if the array's lower bound isn't 1. In other words, does
On 2013-12-18 22:19, I wrote:
On 2013-12-18 22:13, Andrew Dunstan wrote:
On 12/18/2013 03:27 PM, Marko Tiikkaja wrote:
Attached is a patch to add support for array_length(anyarray), which
only works for one-dimensional arrays, returns 0 for empty arrays and
complains if the array's lower bound
,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/19/13, 12:01 AM, David Johnston wrote:
Marko Tiikkaja-4 wrote
On 2013-12-18 22:32, Andrew Dunstan wrote:
You're not really free to assume it - you'll need an exception handler
for the other-than-1 case, or your code might blow up.
This seems to be codifying a bad pattern, which should
) returning *;
a
---
1
(1 row)
INSERT 0 1
local:marko=#* insert into bart values (1) returning *;
a
---
(0 rows)
INSERT 0 0
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/26/13 2:24 PM, Pavel Stehule wrote:
yes, but we can define new statement like \sq+ (Show Query)
There's already \p; might not be too difficult to add a \p+ which would
also show the line numbers.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers
..
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hunk in
progress_report does not conform to the code style guidelines of the
project.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
]..
This part seems clear enough to me, and I don't think repeating that
*three times* is necessary. We already say it twice.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
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
the option_value and either throw an error, or set
the flag appropriately.
Something like the attached?
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 1077,1082 END;
--- 1077,1106
/para
para
for the syntax? The only thing I can think
of is print_strict_params and no_print_strict_params, and I'm not very
fond of that.
Also, in what contexts are unreserved keywords a problem in modern PL/PgSQL?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
suggesting doesn't have this problem?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
shortcut for other use cases.
This idea is good, I like it.
I could prepare a patch for this, unless someone else wants to?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
assertions can't be
caught by exception handlers, but I don't know how that mechanism works
so I'm not sure it's possible. I'll have to look into that.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
I'd say making the ASSERT keyword optional here would be
very confusing.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
meant:
RAISE WHEN true;
would be equivalent to
IF true THEN
RAISE;
END IF;
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/20/13 12:09 PM, Amit Khandekar wrote:
On 16 September 2013 03:43, Marko Tiikkaja ma...@joh.to wrote:
I think it would be extremely surprising if a command like that got
optimized away based on a GUC, so I don't think that would be a good idea.
In pl_gram.y, in the rule stmt_raise
PL/PgSQL
better, and we should just start afresh.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
don't think so it is
practical). It significantly increase a work that is necessary for error
identification.
I think that's a fair point.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
at least a) in 9.4, but I haven't yet looked at how it
could be implemented.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
() and exec_get_dynquery_params()
could do with some brief comments explaining their purpose.
Agreed.
Still agreeing with both of us, added a comment each.
I also added the new keywords to the unreserved_keywords production, as
per the instructions near the beginning of pl_gram.y.
Regards,
Marko Tiikkaja
*** a/doc
for
it working either way. Care to unravel yours a bit more?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-09-17 12:53, Dean Rasheed wrote:
Thanks for the review. Those changes all look sensible to me.
Here's an updated patch incorporating all your fixes, and rebased to
apply without offsets.
Looks good to me. Marking this one ready for committer.
Regards,
Marko Tiikkaja
--
Sent via
for a commitfest
so please let me know if I'm missing something.)
I personally think you did an excellent job. Huge thanks so far!
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
,
Marko Tiikkaja
diff --git a/doc/src/sgml/ref/create_view.sgml
b/doc/src/sgml/ref/create_view.sgml
index 4505290..e0fbe1e 100644
--- a/doc/src/sgml/ref/create_view.sgml
+++ b/doc/src/sgml/ref/create_view.sgml
@@ -440,7 +440,7 @@ CREATE VIEW pg_comedies AS
programlisting
CREATE VIEW comedies
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 15/09/2013 13:50, I wrote:
On 15/09/2013 04:05, Peter Eisentraut wrote:
On Sat, 2013-09-14 at 04:58 +0200, Marko Tiikkaja wrote:
The attached patch (based on Pavel's patch) changes the default to be
slightly more verbose (the CONTEXT lines which were previously
omitted
will be visible
On 2013-09-15 16:34, Peter Eisentraut wrote:
On Sat, 2013-09-14 at 20:47 +0200, Marko Tiikkaja wrote:
Attached is a patch for supporting assertions in PL/PgSQL. These are
similar to the Assert() backend macro: they can be disabled during
compile time, but when enabled, abort execution
it. What should one do in that case?
Writing a patch just to throw it away later because something's
fundamentally broken (or unnacceptable) seems silly if people could have
just looked at the original -HACKERS post and said this can't possibly
work with your current design.
Regards,
Marko
:
1) Is there a reason for the fmt string not being const char*? You
changed it for pg_log_v(), but not for pg_log() and pg_fatal().
2) Allowing PG_FATAL to be passed to pg_log() seems weird, but I
don't feel strongly about that.
Other than that, the patch looks good to me.
Regards,
Marko
that would be a good idea.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
and got shot down quite quickly.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
this to the open commitfest, but feedback is greatly
appreciated.
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 3528,3533 RAISE unique_violation USING MESSAGE = 'Duplicate user ID: '
|| user_id;
--- 3528,3596
/para
/note
, not the postgres server binary.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
this to the open commitfest in hopes of getting some
feedback on this idea (I'm prepared to hear a lot of you're crazy!),
but feel free to comment away any time you please.
Well, I don't know if my feedback above is helpful, but there it is ;-)
Thanks for your input!
Regards,
Marko Tiikkaja
--
Sent via
On 2013-09-14 21:55, Jaime Casanova wrote:
On Sat, Sep 14, 2013 at 1:52 PM, Marko Tiikkaja ma...@joh.to wrote:
And by compile time here, I mean at the time when the PL/PgSQL function
is
compiled, not the postgres server binary.
and compile time means when the function is created
for it.
So can you redesign this without new keyword?
I don't see an easy way to do that, but I'm not too familiar with
PL/PgSQL's parser so maybe I'm just missing something.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 2013-09-14 22:40, I wrote:
Someone may prove me wrong here, but to me it looks like this would only
prevent ASSERT from being used as the name of a PL/PgSQL variable.
The comment at the beginning of pl_scanner.c seems to suggest same.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers
looking into.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
and
is fully reserved. CONSTRAINT? IS?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
what you would put inside the function body for these two, either.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
by default to preserve old behaviour, but
can be extremely useful when debugging code in test environments.
I will add this to the open commitfest, but in the meanwhile, any
feedback is appreciated.
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
think it would be better as a compile time option?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
use the COMPACT mode.
Any thoughts?
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
***
*** 5418,5423 int PQsetClientEncoding(PGconn
*replaceableconn/replaceable, const char *re
--- 5418,5424
typedef enum
{
PQERRORS_TERSE
away any time you please.
Regards,
Marko Tiikkaja
[1]: http://www.postgresql.org/message-id/510bf731.5020...@gmx.net
*** a/src/pl/plpgsql/src/pl_comp.c
--- b/src/pl/plpgsql/src/pl_comp.c
***
*** 351,356 do_compile(FunctionCallInfo fcinfo,
--- 351,357
function
logic.
The b) part here wasn't exactly true; you could use RETURNING TRUE INTO
OK as INSERT/UPDATE/DELETE with RETURNING .. INTO raises an exception if
it returns more than one row, but it's even more convoluted than the
RETURNING TRUE INTO STRICT _OK, and it's repetitive.
Regards,
Marko
On 8/23/13 8:38 AM, Pavel Stehule wrote:
2013/8/22 Marko Tiikkaja ma...@joh.to
I like the idea, but I think this should be a new verbosity level. With
this patch you would have to go full VERBOSE just to debug PL/pgSQL code
with NOTICEs and DEBUGs in it, and that output then becomes harder
an entirely different thing be
consistent?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the idea, but I think this should be a new verbosity level. With
this patch you would have to go full VERBOSE just to debug PL/pgSQL code
with NOTICEs and DEBUGs in it, and that output then becomes harder to
parse with the useless C-code information.
Regards,
Marko Tiikkaja
--
Sent via pgsql
information. With a trivial change the last error
could be:
=# select bar();
ERROR: foo
CONTEXT: PL/pgSQL function foof line 1 RAISE
SQL statement SELECT foof()
PL/pgSQL function bar line 1 at PERFORM
which I find a lot better.
Thoughts?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers
301 - 400 of 655 matches
Mail list logo
