1. 10 Sep, 2008 4 commits
    • Tom Lane's avatar
      Make our parsing of INTERVAL literals spec-compliant (or at least a heck of · f867339c
      Tom Lane authored
      a lot closer than it was before).  To do this, tweak coerce_type() to pass
      through the typmod information when invoking interval_in() on an UNKNOWN
      constant; then fix DecodeInterval to pay attention to the typmod when deciding
      how to interpret a units-less integer value.  I changed one or two other
      details as well.  I believe the code now reacts as expected by spec for all
      the literal syntaxes that are specifically enumerated in the spec.  There
      are corner cases involving strings that don't exactly match the set of fields
      called out by the typmod, for which we might want to tweak the behavior some
      more; but I think this is an area of user friendliness rather than spec
      compliance.  There remain some non-compliant details about the SQL syntax
      (as opposed to what's inside the literal string); but at least we'll throw
      error rather than silently doing the wrong thing in those cases.
      f867339c
    • Alvaro Herrera's avatar
      Add "source file" and "source line" information to each GUC variable. · 3b9ec468
      Alvaro Herrera authored
      initdb forced due to changes in the pg_settings view.
      
      Magnus Hagander and Alvaro Herrera.
      3b9ec468
    • Tom Lane's avatar
      Avoid using sprintf() for a simple octal conversion in PQescapeByteaInternal. · bacf7b20
      Tom Lane authored
      Improves performance, per suggestion from Rudolf Leitgeb (bug #4414).
      The backend did this right already, but not libpq.
      bacf7b20
    • Tom Lane's avatar
      Fix a couple of places where the plpgsql grammar would produce an unhelpful · 3c221c3d
      Tom Lane authored
      'syntax error' message, rather than something that might draw one's
      attention to a missing or wrong-type variable declaration.  Per recent
      gripe.
      3c221c3d
  2. 09 Sep, 2008 2 commits
  3. 08 Sep, 2008 4 commits
  4. 07 Sep, 2008 4 commits
  5. 06 Sep, 2008 2 commits
    • Tom Lane's avatar
      Adjust psql's new \ef command to present an empty CREATE FUNCTION template · 409c144d
      Tom Lane authored
      for editing if no function name is specified.  This seems a much cleaner way
      to offer that functionality than the original patch had.  In passing,
      de-clutter the error displays that are given for a bogus function-name
      argument, and standardize on "$function$" as the default delimiter for the
      function body.  (The original coding would use the shortest possible
      dollar-quote delimiter, which seems to create unnecessarily high risk of
      later conflicts with the user-modified function body.)
      409c144d
    • Tom Lane's avatar
      Implement a psql command "\ef" to edit the definition of a function. · 2c863ca8
      Tom Lane authored
      In support of that, create a backend function pg_get_functiondef().
      The psql command is functional but maybe a bit rough around the edges...
      
      Abhijit Menon-Sen
      2c863ca8
  6. 05 Sep, 2008 7 commits
  7. 04 Sep, 2008 1 commit
  8. 03 Sep, 2008 1 commit
  9. 02 Sep, 2008 1 commit
  10. 01 Sep, 2008 6 commits
  11. 30 Aug, 2008 2 commits
  12. 29 Aug, 2008 5 commits
  13. 28 Aug, 2008 1 commit
    • Tom Lane's avatar
      Extend the parser location infrastructure to include a location field in · a2794623
      Tom Lane authored
      most node types used in expression trees (both before and after parse
      analysis).  This allows us to place an error cursor in many situations
      where we formerly could not, because the information wasn't available
      beyond the very first level of parse analysis.  There's a fair amount
      of work still to be done to persuade individual ereport() calls to actually
      include an error location, but this gets the initdb-forcing part of the
      work out of the way; and the situation is already markedly better than
      before for complaints about unimplementable implicit casts, such as
      CASE and UNION constructs with incompatible alternative data types.
      Per my proposal of a few days ago.
      a2794623