Skip to content
Snippets Groups Projects
  1. Mar 26, 2011
    • Tom Lane's avatar
      Pass collation to makeConst() instead of looking it up internally. · bfa4440c
      Tom Lane authored
      In nearly all cases, the caller already knows the correct collation, and
      in a number of places, the value the caller has handy is more correct than
      the default for the type would be.  (In particular, this patch makes it
      significantly less likely that eval_const_expressions will result in
      changing the exposed collation of an expression.)  So an internal lookup
      is both expensive and wrong.
      bfa4440c
  2. Mar 25, 2011
    • Tom Lane's avatar
      Fix failure to propagate collation in negate_clause(). · c8e99350
      Tom Lane authored
      Turns out it was this, and not so much plpgsql, that was at fault in Stefan
      Huehner's collation-error-in-a-trigger bug report of a couple weeks ago.
      c8e99350
    • Tom Lane's avatar
      Document collation handling in SQL and plpgsql functions. · 9b19c12e
      Tom Lane authored
      This is pretty minimal but covers the bare facts.
      9b19c12e
    • Tom Lane's avatar
      Fix collation handling in plpgsql functions. · a4425e32
      Tom Lane authored
      Make plpgsql treat the input collation as a polymorphism variable, so
      that we cache separate plans for each input collation that's used in a
      particular session, as per recent discussion.  Propagate the input
      collation to all collatable input parameters.
      
      I chose to also propagate the input collation to all declared variables of
      collatable types, which is a bit more debatable but seems to be necessary
      for non-astonishing behavior.  (Copying a parameter into a separate local
      variable shouldn't result in a change of behavior, for example.)  There is
      enough infrastructure here to support declaring a collation for each local
      variable to override that default, but I thought we should wait to see what
      the field demand is before adding such a feature.
      
      In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere.
      
      Documentation patch to follow.
      a4425e32
    • Robert Haas's avatar
      Remove alpha release notes. · f6f0916d
      Robert Haas authored
      Temporarily move some of the alpha release note disclaimers into the regular
      release notes, for the sake of alpha5.
      f6f0916d
    • Robert Haas's avatar
      Make walreceiver send a reply after receiving data but before flushing it. · 30f6136f
      Robert Haas authored
      It originally worked this way, but was changed by commit
      a8a8a3e0, since which time it's been impossible
      for walreceiver to ever send a reply with write_location and flush_location
      set to different values.
      30f6136f
    • Alvaro Herrera's avatar
      Fix broken markup, and remove tabs · 01dd34d5
      Alvaro Herrera authored
      01dd34d5
    • Michael Meskes's avatar
      Documented some ecpg command line options that were missing: · 71ac48fd
      Michael Meskes authored
      -r no_indicator
      -r prepare
      -r questionsmarks
      71ac48fd
    • Tom Lane's avatar
      Fix handling of collation in SQL-language functions. · 27dc7e24
      Tom Lane authored
      Ensure that parameter symbols receive collation from the function's
      resolved input collation, and fix inlining to behave properly.
      
      BTW, this commit lays about 90% of the infrastructure needed to support
      use of argument names in SQL functions.  Parsing of parameters is now
      done via the parser-hook infrastructure ... we'd just need to supply
      a column-ref hook ...
      27dc7e24
  3. Mar 24, 2011
  4. Mar 23, 2011
  5. Mar 22, 2011
    • Tom Lane's avatar
      Make initdb ignore locales for client-only encodings. · 5d1d679d
      Tom Lane authored
      While putting such entries into pg_collation is harmless (since backends
      will ignore entries that don't match the database encoding), it's also
      useless.
      5d1d679d
    • Tom Lane's avatar
      Improve reporting of run-time-detected indeterminate-collation errors. · 6e197cb2
      Tom Lane authored
      pg_newlocale_from_collation does not have enough context to give an error
      message that's even a little bit useful, so move the responsibility for
      complaining up to its callers.  Also, reword ERRCODE_INDETERMINATE_COLLATION
      error messages in a less jargony, more message-style-guide-compliant
      fashion.
      6e197cb2
    • Tom Lane's avatar
      Throw error for indeterminate collation of an ORDER/GROUP/DISTINCT target. · 37d6d07d
      Tom Lane authored
      This restores a parse error that was thrown (though only in the ORDER BY
      case) by the original collation patch.  I had removed it in my recent
      revisions because it was thrown at a place where collations now haven't
      been computed yet; but I thought of another way to handle it.
      
      Throwing the error at parse time, rather than leaving it to be done at
      runtime, is good because a syntax error pointer is helpful for localizing
      the problem.  We can reasonably assume that the comparison function for a
      collatable datatype will complain if it doesn't have a collation to use.
      Now the planner might choose to implement GROUP or DISTINCT via hashing,
      in which case no runtime error would actually occur, but it seems better
      to throw error consistently rather than let the error depend on what the
      planner chooses to do.  Another possible objection is that the user might
      specify a nondefault sort operator that doesn't care about collation
      ... but that's surely an uncommon usage, and it wouldn't hurt him to throw
      in a COLLATE clause anyway.  This change also makes the ORDER BY/GROUP
      BY/DISTINCT case more consistent with the UNION/INTERSECT/EXCEPT case,
      which was already coded to throw this error even though the same objections
      could be raised there.
      37d6d07d
    • Tom Lane's avatar
      Avoid potential deadlock in InitCatCachePhase2(). · 1192ba8b
      Tom Lane authored
      Opening a catcache's index could require reading from that cache's own
      catalog, which of course would acquire AccessShareLock on the catalog.
      So the original coding here risks locking index before heap, which could
      deadlock against another backend trying to get exclusive locks in the
      normal order.  Because InitCatCachePhase2 is only called when a backend
      has to start up without a relcache init file, the deadlock was seldom seen
      in the field.  (And by the same token, there's no need to worry about any
      performance disadvantage; so not much point in trying to distinguish
      exactly which catalogs have the risk.)
      
      Bug report, diagnosis, and patch by Nikhil Sontakke.  Additional commentary
      by me.  Back-patch to all supported branches.
      1192ba8b
    • Simon Riggs's avatar
    • Tom Lane's avatar
      Reimplement planner's handling of MIN/MAX aggregate optimization (again). · 8df08c84
      Tom Lane authored
      Instead of playing cute games with pathkeys, just build a direct
      representation of the intended sub-select, and feed it through
      query_planner to get a Path for the index access.  This is a bit slower
      than 9.1's previous method, since we'll duplicate most of the overhead of
      query_planner; but since the whole optimization only applies to rather
      simple single-table queries, that probably won't be much of a problem in
      practice.  The advantage is that we get to do the right thing when there's
      a partial index that needs the implicit IS NOT NULL clause to be usable.
      Also, although this makes planagg.c be a bit more closely tied to the
      ordering of operations in grouping_planner, we can get rid of some coupling
      to lower-level parts of the planner.  Per complaint from Marti Raudsepp.
      8df08c84
  6. Mar 21, 2011
  7. Mar 20, 2011
    • Bruce Momjian's avatar
    • Tom Lane's avatar
      Add some platform-independent tests for the collation feature. · 9b095fbe
      Tom Lane authored
      There's a lot we can't test very well without platform dependencies,
      but the C/POSIX collations should now work the same way everywhere.
      9b095fbe
    • Tom Lane's avatar
      Suppress platform-dependent unused-variable warning. · 82e4d45b
      Tom Lane authored
      The local variable "sock" can be unused depending on compilation flags.
      But there seems no particular need for it, since the kernel calls can
      just as easily say port->sock instead.
      82e4d45b
    • Tom Lane's avatar
      Fix up handling of C/POSIX collations. · 176d5bae
      Tom Lane authored
      Install just one instance of the "C" and "POSIX" collations into
      pg_collation, rather than one per encoding.  Make these instances exist
      and do something useful even in machines without locale_t support: to wit,
      it's now possible to force comparisons and case-folding functions to use C
      locale in an otherwise non-C database, whether or not the platform has
      support for using any additional collations.
      
      Fix up severely broken upper/lower/initcap functions, too: the C/POSIX
      fastpath now does what it is supposed to, and non-default collations are
      handled correctly in single-byte database encodings.
      
      Merge the two separate collation hashtables that were being maintained in
      pg_locale.c, and be more wary of the possibility that we fail partway
      through filling a cache entry.
      176d5bae
    • Bruce Momjian's avatar
      Move PITR and StreamingRep up one level of heading in the 9.1 release · c2f4ea46
      Bruce Momjian authored
      notes.
      
      Remove excessive linking to pg_ctl manual page.
      
      Reorder incompatibility sections.
      c2f4ea46
    • Magnus Hagander's avatar
      Misc minor fixes to 9.1 release notes · 0f96ae64
      Magnus Hagander authored
      Thom Brown
      0f96ae64
    • Bruce Momjian's avatar
      Word-wrap 9.1 release note lines. · 08607c95
      Bruce Momjian authored
      08607c95
    • Bruce Momjian's avatar
      b2c5b3d1
    • Tom Lane's avatar
      Revise collation derivation method and expression-tree representation. · b310b6e3
      Tom Lane authored
      All expression nodes now have an explicit output-collation field, unless
      they are known to only return a noncollatable data type (such as boolean
      or record).  Also, nodes that can invoke collation-aware functions store
      a separate field that is the collation value to pass to the function.
      This avoids confusion that arises when a function has collatable inputs
      and noncollatable output type, or vice versa.
      
      Also, replace the parser's on-the-fly collation assignment method with
      a post-pass over the completed expression tree.  This allows us to use
      a more complex (and hopefully more nearly spec-compliant) assignment
      rule without paying for it in extra storage in every expression node.
      
      Fix assorted bugs in the planner's handling of collations by making
      collation one of the defining properties of an EquivalenceClass and
      by converting CollateExprs into discardable RelabelType nodes during
      expression preprocessing.
      b310b6e3
  8. Mar 19, 2011
Loading