1. 31 Mar, 2005 2 commits
  2. 30 Mar, 2005 3 commits
  3. 29 Mar, 2005 5 commits
    • Tom Lane's avatar
      Add proallargtypes and proargmodes columns to pg_proc, as per my earlier · 0f085f6e
      Tom Lane authored
      proposal for OUT parameter support.  The columns don't actually *do*
      anything yet, they are just left NULLs.  But I thought I'd commit this
      part separately as a fairly pure example of the tasks needed when adding
      a column to pg_proc or one of the other core system tables.
      0f085f6e
    • Tom Lane's avatar
      Fix grammar for IN/OUT/INOUT parameters. This commit doesn't actually · eb47ee48
      Tom Lane authored
      implement any new feature, it just pushes the 'not implemented' error
      message deeper into the backend.  I also tweaked the grammar to accept
      Oracle-ish parameter syntax (parameter name first), as well as the
      SQL99 standard syntax (parameter mode first), since it was easy and
      people will doubtless try to use both anyway.
      eb47ee48
    • Tom Lane's avatar
      Officially decouple FUNC_MAX_ARGS from INDEX_MAX_KEYS, and set the · 8c85a34a
      Tom Lane authored
      former to 100 by default.  Clean up some of the less necessary
      dependencies on FUNC_MAX_ARGS; however, the biggie (FunctionCallInfoData)
      remains.
      8c85a34a
    • Neil Conway's avatar
      4f6f5db4
    • Tom Lane's avatar
      Convert oidvector and int2vector into variable-length arrays. This · 70c9763d
      Tom Lane authored
      change saves a great deal of space in pg_proc and its primary index,
      and it eliminates the former requirement that INDEX_MAX_KEYS and
      FUNC_MAX_ARGS have the same value.  INDEX_MAX_KEYS is still embedded
      in the on-disk representation (because it affects index tuple header
      size), but FUNC_MAX_ARGS is not.  I believe it would now be possible
      to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet.
      There are still a lot of vestigial references to FUNC_MAX_ARGS, which
      I will clean up in a separate pass.  However, getting rid of it
      altogether would require changing the FunctionCallInfoData struct,
      and I'm not sure I want to buy into that.
      70c9763d
  4. 28 Mar, 2005 2 commits
    • Tom Lane's avatar
      Remove dead push/pop rollback code. Vadim once planned to implement · 11919160
      Tom Lane authored
      transaction rollback via UNDO but I think that's highly unlikely to
      happen, so we may as well remove the stubs.  (Someday we ought to
      rip out the stub xxx_undo routines, too.)  Per Alvaro.
      11919160
    • Tom Lane's avatar
      Rethink the order of expression preprocessing: eval_const_expressions · 5db2e838
      Tom Lane authored
      really ought to run before canonicalize_qual, because it can now produce
      forms that canonicalize_qual knows how to improve (eg, NOT clauses).
      Also, because eval_const_expressions already knows about flattening
      nested ANDs and ORs into N-argument form, the initial flatten_andors
      pass in canonicalize_qual is now completely redundant and can be
      removed.  This doesn't save a whole lot of code, but the time and
      palloc traffic eliminated is a useful gain on large expression trees.
      5db2e838
  5. 27 Mar, 2005 4 commits
  6. 26 Mar, 2005 7 commits
  7. 25 Mar, 2005 14 commits
  8. 24 Mar, 2005 3 commits