1. 10 Jul, 2019 1 commit
  2. 09 Jul, 2019 5 commits
  3. 08 Jul, 2019 5 commits
  4. 07 Jul, 2019 2 commits
  5. 06 Jul, 2019 5 commits
  6. 05 Jul, 2019 8 commits
  7. 04 Jul, 2019 10 commits
  8. 03 Jul, 2019 4 commits
    • Tom Lane's avatar
      Ensure plpgsql result tuples have the right composite type marking. · 5683b349
      Tom Lane authored
      A function that is declared to return a named composite type must
      return tuple datums that are physically marked as having that type.
      The plpgsql code path that allowed directly returning an expanded-record
      datum forgot to check that, so that an expanded record marked as type
      RECORDOID could be returned if it had a physically-compatible tupdesc.
      This'd be harmless, I think, if the record value never escaped the
      current session --- but it's possible for it to get stored into a table,
      and then subsequent sessions can't interpret the anonymous record type.
      
      Fix by flattening the record into a tuple datum and overwriting its
      type/typmod fields, if its declared type doesn't match the function's
      declared type.  (In principle it might be possible to just change the
      expanded record's stored type ID info, but there are enough tricky
      consequences that I didn't want to mess with that, especially not in
      a back-patched bug fix.)
      
      Per bug report from Steve Rogerson.  Back-patch to v11 where the bug
      was introduced.
      
      Discussion: https://postgr.es/m/cbaecae6-7b87-584e-45f6-4d047b92ca2a@yewtc.demon.co.uk
      5683b349
    • Tom Lane's avatar
      Doc: document table persistence display in \dt+. · 03e7b302
      Tom Lane authored
      Forgotten in commit 9a2ea618.
      03e7b302
    • Tom Lane's avatar
      Show table persistence in psql's \dt+ and related commands. · 9a2ea618
      Tom Lane authored
      In verbose mode, listTables() now emits a "Persistence" column
      showing whether the table/index/view/etc is permanent, temporary,
      or unlogged.
      
      David Fetter, reviewed by Fabien Coelho and Rafia Sabih
      
      Discussion: https://postgr.es/m/20190423005642.GZ28936@fetter.org
      9a2ea618
    • David Rowley's avatar
      Don't remove surplus columns from GROUP BY for inheritance parents · a5be4062
      David Rowley authored
      d4c3a156 added code to remove columns that were not part of a table's
      PRIMARY KEY constraint from the GROUP BY clause when all the primary key
      columns were present in the group by.  This is fine to do since we know
      that there will only be one row per group coming from this relation.
      However, the logic failed to consider inheritance parent relations.  These
      can have child relations without a primary key, but even if they did, they
      could duplicate one of the parent's rows or one from another child
      relation.  In this case, those additional GROUP BY columns are required.
      
      Fix this by disabling the optimization for inheritance parent tables.
      In v11 and beyond, partitioned tables are fine since partitions cannot
      overlap and before v11 partitioned tables could not have a primary key.
      
      Reported-by: Manuel Rigger
      Discussion: http://postgr.es/m/CA+u7OA7VLKf_vEr6kLF3MnWSA9LToJYncgpNX2tQ-oWzYCBQAw@mail.gmail.com
      Backpatch-through: 9.6
      a5be4062