Skip to content
Snippets Groups Projects
  1. Jun 09, 2000
  2. Apr 12, 2000
  3. Feb 15, 2000
  4. Jan 27, 2000
    • Tom Lane's avatar
      Redesign DISTINCT ON as discussed in pgsql-sql 1/25/00: syntax is now · dd979f66
      Tom Lane authored
      SELECT DISTINCT ON (expr [, expr ...]) targetlist ...
      and there is a check to make sure that the user didn't specify an ORDER BY
      that's incompatible with the DISTINCT operation.
      Reimplement nodeUnique and nodeGroup to use the proper datatype-specific
      equality function for each column being compared --- they used to do
      bitwise comparisons or convert the data to text strings and strcmp().
      (To add insult to injury, they'd look up the conversion functions once
      for each tuple...)  Parse/plan representation of DISTINCT is now a list
      of SortClause nodes.
      initdb forced by querytree change...
      dd979f66
  5. Jan 26, 2000
    • Bruce Momjian's avatar
      Add: · 5c25d602
      Bruce Momjian authored
        * Portions Copyright (c) 1996-2000, PostgreSQL, Inc
      
      to all files copyright Regents of Berkeley.  Man, that's a lot of files.
      5c25d602
  6. Aug 21, 1999
    • Tom Lane's avatar
      Major revision of sort-node handling: push knowledge of query · db436adf
      Tom Lane authored
      sort order down into planner, instead of handling it only at the very top
      level of the planner.  This fixes many things.  An explicit sort is now
      avoided if there is a cheaper alternative (typically an indexscan) not
      only for ORDER BY, but also for the internal sort of GROUP BY.  It works
      even when there is no other reason (such as a WHERE condition) to consider
      the indexscan.  It works for indexes on functions.  It works for indexes
      on functions, backwards.  It's just so cool...
      
      CAUTION: I have changed the representation of SortClause nodes, therefore
      THIS UPDATE BREAKS STORED RULES.  You will need to initdb.
      db436adf
  7. Jul 19, 1999
    • Tom Lane's avatar
      Rewrite parser's handling of INSERT ... SELECT so that processing · 7f76eab1
      Tom Lane authored
      of the SELECT part of the statement is just like a plain SELECT.  All
      INSERT-specific processing happens after the SELECT parsing is done.
      This eliminates many problems, e.g. INSERT ... SELECT ... GROUP BY using
      the wrong column labels.  Ensure that DEFAULT clauses are coerced to
      the target column type, whether or not stored clause produces the right
      type.  Substantial cleanup of parser's array support.
      7f76eab1
  8. Jul 16, 1999
  9. Jul 15, 1999
  10. May 26, 1999
  11. Feb 23, 1999
  12. Sep 01, 1998
  13. Feb 26, 1998
  14. Dec 29, 1997
  15. Nov 26, 1997
  16. Nov 25, 1997
Loading