1. 14 Aug, 2006 5 commits
    • Tom Lane's avatar
      Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking · 3d1e01ca
      Tom Lane authored
      as per yesterday's proposal.  Also make things a tad more orthogonal by
      adding the recent STRICT addition to EXECUTE INTO.
      Jonah Harris and Tom Lane
      3d1e01ca
    • Tom Lane's avatar
      When executing a list of queries derived from rule expansion, · 29fa0513
      Tom Lane authored
      _SPI_execute_plan's return code should reflect the type of the query
      that is marked canSetTag, not necessarily the last one in the list.
      
      This is arguably a bug fix, but I'm hesitant to back-patch it because
      it's the sort of subtle change that might break someone's code, and it's
      best not to do that kind of thing in point releases.
      29fa0513
    • Tom Lane's avatar
      Remove hash_destroy calls in hash_create's failure paths. As noted by · c859294c
      Tom Lane authored
      a Coverity warning, these are risky since the hashtable isn't necessarily
      fully set up yet.  They're unnecessary anyway: a deletable hashtable
      should be in a memory context that will be cleared following elog(ERROR).
      Per report from Martijn van Oosterhout.
      c859294c
    • Bruce Momjian's avatar
      Revert (again) GUC patch to return commented fields to their default · f0584518
      Bruce Momjian authored
      values, due to concern about the patch.
      f0584518
    • Tom Lane's avatar
      Get rid of "lookahead" functionality in plpgsql's yylex() function, · 36481474
      Tom Lane authored
      and instead make the grammar production for the RETURN statement do the
      heavy lifting.  The lookahead idea was copied from the main parser, but
      it does not work in plpgsql's parser because here gram.y looks explicitly
      at the scanner's yytext variable, which will be out of sync after a
      failed lookahead step.  A minimal example is
      
      create or replace function foo() returns void language plpgsql as '
      begin
        perform return foo bar;
      end';
      
      which can be seen by testing to deliver "foo foo bar" to the main parser
      instead of the expected "return foo bar".  This isn't a huge bug since
      RETURN is not found in the main grammar, but it could bite someone who
      tried to use "return" as an identifier.
      
      Back-patch to 8.1.  Bug exists further back, but HEAD patch doesn't apply
      cleanly, and given the lack of field complaints it doesn't seem worth
      the effort to develop adjusted patches.
      36481474
  2. 13 Aug, 2006 11 commits
  3. 12 Aug, 2006 8 commits
  4. 11 Aug, 2006 11 commits
  5. 10 Aug, 2006 4 commits
  6. 09 Aug, 2006 1 commit