Skip to content
Snippets Groups Projects
  1. Jun 23, 2004
  2. Jun 21, 2004
  3. Jun 19, 2004
  4. Jun 18, 2004
  5. Jun 16, 2004
    • Tom Lane's avatar
      Represent type-specific length coercion functions as pg_cast entries, · d70a42e6
      Tom Lane authored
      eliminating the former hard-wired convention about their names.  Allow
      pg_cast entries to represent both type coercion and length coercion in
      a single step --- this is represented by a function that takes an
      extra typmod argument, just like a length coercion function.  This
      nicely merges the type and length coercion mechanisms into something
      at least a little cleaner than we had before.  Make use of the single-
      coercion-step behavior to fix integer-to-bit coercion so that coercing
      to bit(n) yields the rightmost n bits of the integer instead of the
      leftmost n bits.  This should fix recurrent complaints about the odd
      behavior of this coercion.  Clean up the documentation of the bit string
      functions, and try to put it where people might actually find it.
      Also, get rid of the unreliable heuristics in ruleutils.c about whether
      to display nested coercion steps; instead require parse_coerce.c to
      label them properly in the first place.
      d70a42e6
  6. Jun 14, 2004
  7. Jun 13, 2004
  8. Jun 11, 2004
    • Tom Lane's avatar
      StrategyDirtyBufferList wasn't being careful to honor max_buffers limit. · bbf0ebad
      Tom Lane authored
      Bug is only latent given that sole caller is passing NBuffers, but it
      could bite someone in the rear someday.
      bbf0ebad
    • Tom Lane's avatar
      Add some code to Assert that when we release pin on a buffer, we are · e6cba715
      Tom Lane authored
      not holding the buffer's cntx_lock or io_in_progress_lock.  A recent
      report from Litao Wu makes me wonder whether it is ever possible for
      us to drop a buffer and forget to release its cntx_lock.  The Assert
      does not fire in the regression tests, but that proves little ...
      e6cba715
    • Bruce Momjian's avatar
      >> It certainly doesn't. There still was a bug with the locale stuff, · 3a8cdf33
      Bruce Momjian authored
      >> though - the GUC variable was not set in the child
      >processes. So "show
      >> lc_collate" would *always* return "C", for example. attached
      >patch fixes
      >> this.
      >
      >Hm.  Why were these vars not propagated by the regular
      >mechanism for GUC
      >variables (write_nondefault_variables or whatever it's called)?  If the
      >problem is that it's not accepting PGC_INTERNAL values, then we need to
      >fix it there not here, because otherwise we'll have to pass all the
      >PGC_INTERNAL variables through the backend_variables file, which seems
      >like a recipe for more of the same sort of bug.
      
      
      Good point :-(
      
      I think the problem is not only that it specifically does not deal with
      PGC_INTERNAL variables. The problem is in the fact that
      write_nondefault_variables is called *before* the locale is read
      (because the locale is read from pg_control and not from any of the
      "usual" ways to read it).
      
      Attached patch is another stab at fixing it. It makes postmaster dump a
      new copy of the file once it has started the database (before it accepts
      any connections), which is when it will know about these parameters.
      Also updates the reading code to set the context to the one where the
      variable was originally set (PGC_POSTMASTER won't work for PGC_INTERNAL,
      and the other way around).
      
      We still pass lc_collate through the special file, because
      set_config_option on lc_collate will speficially *not* call setlocale(),
      and we need that call. But we no longer call set_config_option from
      there.
      
      Magnus Hagander
      3a8cdf33
    • Tom Lane's avatar
      When using extended-query protocol, postpone planning of unnamed statements · 7643bed5
      Tom Lane authored
      until Bind is received, so that actual parameter values are visible to the
      planner.  Make use of the parameter values for estimation purposes (but
      don't fold them into the actual plan).  This buys back most of the
      potential loss of plan quality that ensues from using out-of-line
      parameters instead of putting literal values right into the query text.
      
      This patch creates a notion of constant-folding expressions 'for
      estimation purposes only', in which case we can be more aggressive than
      the normal eval_const_expressions() logic can be.  Right now the only
      difference in behavior is inserting bound values for Params, but it will
      be interesting to look at other possibilities.  One that we've seen
      come up repeatedly is reducing now() and related functions to current
      values, so that queries like ... WHERE timestampcol > now() - '1 day'
      have some chance of being planned effectively.
      
      Oliver Jowett, with some kibitzing from Tom Lane.
      7643bed5
    • Bruce Momjian's avatar
      Attached is a patch that takes care of the PATHSEP issue. I made a more · 6cc4175b
      Bruce Momjian authored
      extensive change then what was suggested. I found the file path.c that
      contained a lot of "Unix/Windows" agnostic functions so I added a function
      there instead and removed the PATHSEP declaration in exec.c altogether. All
      to keep things from scattering all over the code.
      
      I also took the liberty of changing the name of the functions
      "first_path_sep" and "last_path_sep". Where I come from (and I'm apparently
      not alone given the former macro name PATHSEP), they should be called
      "first_dir_sep" and "last_dir_sep". The new function I introduced, that
      actually finds path separators, is now the "first_path_sep". The patch
      contains changes on all affected places of course.
      
      I also changed the documentation on dynamic_library_path to reflect the
      chagnes.
      
      Thomas Hallgren
      6cc4175b
  9. Jun 10, 2004
  10. Jun 09, 2004
  11. Jun 08, 2004
  12. Jun 07, 2004
  13. Jun 06, 2004
  14. Jun 05, 2004
    • Tom Lane's avatar
      Tweak palloc/repalloc to allow zero bytes to be requested, as per recent · c3a153af
      Tom Lane authored
      proposal.  Eliminate several dozen now-unnecessary hacks to avoid palloc(0).
      (It's likely there are more that I didn't find.)
      c3a153af
    • Tom Lane's avatar
      Make the world very nearly safe for composite-type columns in tables. · ae93e5fd
      Tom Lane authored
      1. Solve the problem of not having TOAST references hiding inside composite
      values by establishing the rule that toasting only goes one level deep:
      a tuple can contain toasted fields, but a composite-type datum that is
      to be inserted into a tuple cannot.  Enforcing this in heap_formtuple
      is relatively cheap and it avoids a large increase in the cost of running
      the tuptoaster during final storage of a row.
      2. Fix some interesting problems in expansion of inherited queries that
      reference whole-row variables.  We never really did this correctly before,
      but it's now relatively painless to solve by expanding the parent's
      whole-row Var into a RowExpr() selecting the proper columns from the
      child.
      If you dike out the preventive check in CheckAttributeType(),
      composite-type columns now seem to actually work.  However, we surely
      cannot ship them like this --- without I/O for composite types, you
      can't get pg_dump to dump tables containing them.  So a little more
      work still to do.
      ae93e5fd
  15. Jun 04, 2004
    • Tom Lane's avatar
      Resurrect heap_deformtuple(), this time implemented as a singly nested · 8f2ea8b7
      Tom Lane authored
      loop over the fields instead of a loop around heap_getattr.  This is
      considerably faster (O(N) instead of O(N^2)) when there are nulls or
      varlena fields, since those prevent use of attcacheoff.  Replace loops
      over heap_getattr with heap_deformtuple in situations where all or most
      of the fields have to be fetched, such as printtup and tuptoaster.
      Profiling done more than a year ago shows that this should be a nice
      win for situations involving many-column tables.
      8f2ea8b7
    • Tom Lane's avatar
      Remove some long-obsolete code that was causing a strange error message · 223b813d
      Tom Lane authored
      when someone attempts to create a column of a composite datatype.  For
      now, just make sure we produce a reasonable error at the 'right place'.
      Not sure if this will be made to work before 7.5, but make it act
      reasonably in case nothing more gets done.
      223b813d
Loading