On Mon, Oct 24, 2011 at 01:26, Tom Lane t...@sss.pgh.pa.us wrote:
Andreas Karlsson andr...@proxel.se writes:
Thanks for cleaning up the code to some sanity, I should have done so
myself when I noticed the problem.
A new version is attached.
Committed with minor adjustments --- I didn't see
Andreas Karlsson andr...@proxel.se writes:
Thanks for cleaning up the code to some sanity, I should have done so
myself when I noticed the problem.
A new version is attached.
Committed with minor adjustments --- I didn't see any need to make this
wait for the next commitfest.
On Thu, Oct 20, 2011 at 5:16 PM, Andreas Karlsson andr...@proxel.se wrote:
A new version is attached.
Looks fine. Marking ready for committer (CF 2011-11).
Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Excerpts from Josh Kupershmidt's message of mié oct 19 23:50:58 -0300 2011:
On Wed, Oct 19, 2011 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Kupershmidt schmi...@gmail.com writes:
Incidentally, I was wondering what the heck was up with a clause like this:
else if
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Josh Kupershmidt's message of mié oct 19 23:50:58 -0300 2011:
I assume this is an accepted quirk of previous_word() since we have
this existing similar code:
Maybe both are wrong, though the DROP case seems to work so maybe it's
I wrote:
What I suggest is that we redefine previous_word() as returning an empty
string, not NULL, anytime there is no such preceding word. This is
better than the current behavior because (a) it's less surprising and
(b) it's not ambiguous. Right now the caller can't tell the difference
On 10/20/2011 09:53 PM, Tom Lane wrote:
With that change, the correct test at line 795 would become
else if (pg_strcasecmp(prev_wd, DROP) == 0
prev2_wd[0] == '\0')
I've committed this --- please adjust the EXECUTE patch to match.
Thanks for cleaning up the code to some
On Mon, Sep 26, 2011 at 5:03 PM, Andreas Karlsson andr...@proxel.se wrote:
Magnus's patch for adding tab completion of views to the TABLE statement
reminded me of a minor annoyance of mine -- that EXECUTE always completes
with PROCEDURE as if it would have been part of CREATE TRIGGER ...
Josh Kupershmidt schmi...@gmail.com writes:
Incidentally, I was wondering what the heck was up with a clause like this:
else if (pg_strcasecmp(prev_wd, EXECUTE) == 0
pg_strcasecmp(prev2_wd, EXECUTE) == 0)
Hmm, maybe || was meant not ? It seems pretty unlikely that the
above
On Wed, Oct 19, 2011 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Kupershmidt schmi...@gmail.com writes:
Incidentally, I was wondering what the heck was up with a clause like this:
else if (pg_strcasecmp(prev_wd, EXECUTE) == 0
pg_strcasecmp(prev2_wd, EXECUTE) == 0)
Hi,
Magnus's patch for adding tab completion of views to the TABLE statement
reminded me of a minor annoyance of mine -- that EXECUTE always
completes with PROCEDURE as if it would have been part of CREATE
TRIGGER ... EXECUTE even when it is the first word of the line.
Attached is a simple
11 matches
Mail list logo
