1. 03 Aug, 2021 1 commit
  2. 12 May, 2021 1 commit
    • Tom Lane's avatar
      Initial pgindent and pgperltidy run for v14. · def5b065
      Tom Lane authored
      Also "make reformat-dat-files".
      
      The only change worthy of note is that pgindent messed up the formatting
      of launcher.c's struct LogicalRepWorkerId, which led me to notice that
      that struct wasn't used at all anymore, so I just took it out.
      def5b065
  3. 29 Apr, 2021 2 commits
    • Tom Lane's avatar
      Improve wording of some pg_upgrade failure reports. · c9c37ae0
      Tom Lane authored
      Don't advocate dropping a whole table when dropping a column would
      serve.  While at it, try to make the layout of these messages a
      bit cleaner and more consistent.
      
      Per suggestion from Daniel Gustafsson.  No back-patch, as we generally
      don't like to churn translatable messages in released branches.
      
      Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us
      c9c37ae0
    • Tom Lane's avatar
      Fix some more omissions in pg_upgrade's tests for non-upgradable types. · 57c081de
      Tom Lane authored
      Commits 29aeda6e et al closed up some oversights involving not checking
      for non-upgradable types within container types, such as arrays and
      ranges.  However, I only looked at version.c, failing to notice that
      there were substantially-equivalent tests in check.c.  (The division
      of responsibility between those files is less than clear...)
      
      In addition, because genbki.pl does not guarantee that auto-generated
      rowtype OIDs will hold still across versions, we need to consider that
      the composite type associated with a system catalog or view is
      non-upgradable.  It seems unlikely that someone would have a user
      column declared that way, but if they did, trying to read it in another
      PG version would likely draw "no such pg_type OID" failures, thanks
      to the type OID embedded in composite Datums.
      
      To support the composite and reg*-type cases, extend the recursive
      query that does the search to allow any base query that returns
      a column of pg_type OIDs, rather than limiting it to exactly one
      starting type.
      
      As before, back-patch to all supported branches.
      
      Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us
      57c081de
  4. 12 Apr, 2021 1 commit
  5. 01 Apr, 2021 1 commit
    • Heikki Linnakangas's avatar
      Add 'noError' argument to encoding conversion functions. · ea1b99a6
      Heikki Linnakangas authored
      With the 'noError' argument, you can try to convert a buffer without
      knowing the character boundaries beforehand. The functions now need to
      return the number of input bytes successfully converted.
      
      This is is a backwards-incompatible change, if you have created a custom
      encoding conversion with CREATE CONVERSION. This adds a check to
      pg_upgrade for that, refusing the upgrade if there are any user-defined
      encoding conversions. Custom conversions are very rare, there are no
      commonly used extensions that I know of that uses that feature. No other
      objects can depend on conversions, so if you do have one, you can fairly
      easily drop it before upgrading, and recreate it after the upgrade with
      an updated version.
      
      Add regression tests for built-in encoding conversions. This doesn't cover
      every conversion, but it covers all the internal functions in conv.c that
      are used to implement the conversions.
      
      Reviewed-by: John Naylor
      Discussion: https://www.postgresql.org/message-id/e7861509-3960-538a-9025-b75a61188e01%40iki.fi
      ea1b99a6
  6. 02 Jan, 2021 1 commit
  7. 28 Dec, 2020 1 commit
  8. 25 Dec, 2020 1 commit
  9. 24 Dec, 2020 1 commit
  10. 09 Nov, 2020 1 commit
  11. 16 Oct, 2020 1 commit
  12. 15 Oct, 2020 1 commit
  13. 06 Oct, 2020 2 commits
  14. 17 Sep, 2020 1 commit
    • Tom Lane's avatar
      Remove support for postfix (right-unary) operators. · 1ed6b895
      Tom Lane authored
      This feature has been a thorn in our sides for a long time, causing
      many grammatical ambiguity problems.  It doesn't seem worth the
      pain to continue to support it, so remove it.
      
      There are some follow-on improvements we can make in the grammar,
      but this commit only removes the bare minimum number of productions,
      plus assorted backend support code.
      
      Note that pg_dump and psql continue to have full support, since
      they may be used against older servers.  However, pg_dump warns
      about postfix operators.  There is also a check in pg_upgrade.
      
      Documentation-wise, I (tgl) largely removed the "left unary"
      terminology in favor of saying "prefix operator", which is
      a more standard and IMO less confusing term.
      
      I included a catversion bump, although no initial catalog data
      changes here, to mark the boundary at which oprkind = 'r'
      stopped being valid in pg_operator.
      
      Mark Dilger, based on work by myself and Robert Haas;
      review by John Naylor
      
      Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
      1ed6b895
  15. 18 Mar, 2020 1 commit
  16. 01 Jan, 2020 1 commit
  17. 28 Nov, 2019 2 commits
  18. 25 Oct, 2019 1 commit
  19. 14 Oct, 2019 1 commit
    • Tomas Vondra's avatar
      Check for tables with sql_identifier during pg_upgrade · 0ccfc282
      Tomas Vondra authored
      Commit 7c15cef8 changed sql_identifier data type to be based on name
      instead of varchar.  Unfortunately, this breaks on-disk format for this
      data type.  Luckily, that should be a very rare problem, as this data
      type is used only in information_schema views, so this only affects user
      objects (tables, materialized views and indexes).  One way to end in
      such situation is to do CTAS with a query on those system views.
      
      There are two options to deal with this - we can either abort pg_upgrade
      if there are user objects with sql_identifier columns in pg_upgrade, or
      we could replace the sql_identifier type with varchar.  Considering how
      rare the issue is expected to be, and the complexity of replacing the
      data type (e.g. in matviews), we've decided to go with the simple check.
      
      The query is somewhat complex - the sql_identifier data type may be used
      indirectly - through a domain, a composite type or both, possibly in
      multiple levels.  Detecting this requires a recursive CTE.
      
      Backpatch to 12, where the sql_identifier definition changed.
      
      Reported-by: Hans Buschmann
      Author: Tomas Vondra
      Reviewed-by: Tom Lane
      Backpatch-to: 12
      Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
      0ccfc282
  20. 09 Oct, 2019 1 commit
  21. 29 Apr, 2019 1 commit
  22. 02 Jan, 2019 1 commit
  23. 27 Nov, 2018 2 commits
  24. 21 Nov, 2018 1 commit
    • Andres Freund's avatar
      Remove WITH OIDS support, change oid catalog column visibility. · 578b2297
      Andres Freund authored
      Previously tables declared WITH OIDS, including a significant fraction
      of the catalog tables, stored the oid column not as a normal column,
      but as part of the tuple header.
      
      This special column was not shown by default, which was somewhat odd,
      as it's often (consider e.g. pg_class.oid) one of the more important
      parts of a row.  Neither pg_dump nor COPY included the contents of the
      oid column by default.
      
      The fact that the oid column was not an ordinary column necessitated a
      significant amount of special case code to support oid columns. That
      already was painful for the existing, but upcoming work aiming to make
      table storage pluggable, would have required expanding and duplicating
      that "specialness" significantly.
      
      WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
      Remove it.
      
      Removing includes:
      - CREATE TABLE and ALTER TABLE syntax for declaring the table to be
        WITH OIDS has been removed (WITH (oids[ = true]) will error out)
      - pg_dump does not support dumping tables declared WITH OIDS and will
        issue a warning when dumping one (and ignore the oid column).
      - restoring an pg_dump archive with pg_restore will warn when
        restoring a table with oid contents (and ignore the oid column)
      - COPY will refuse to load binary dump that includes oids.
      - pg_upgrade will error out when encountering tables declared WITH
        OIDS, they have to be altered to remove the oid column first.
      - Functionality to access the oid of the last inserted row (like
        plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
      
      The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
      for CREATE TABLE) is still supported. While that requires a bit of
      support code, it seems unnecessary to break applications / dumps that
      do not use oids, and are explicit about not using them.
      
      The biggest user of WITH OID columns was postgres' catalog. This
      commit changes all 'magic' oid columns to be columns that are normally
      declared and stored. To reduce unnecessary query breakage all the
      newly added columns are still named 'oid', even if a table's column
      naming scheme would indicate 'reloid' or such.  This obviously
      requires adapting a lot code, mostly replacing oid access via
      HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
      
      The bootstrap process now assigns oids for all oid columns in
      genbki.pl that do not have an explicit value (starting at the largest
      oid previously used), only oids assigned later by oids will be above
      FirstBootstrapObjectId. As the oid column now is a normal column the
      special bootstrap syntax for oids has been removed.
      
      Oids are not automatically assigned during insertion anymore, all
      backend code explicitly assigns oids with GetNewOidWithIndex(). For
      the rare case that insertions into the catalog via SQL are called for
      the new pg_nextoid() function can be used (which only works on catalog
      tables).
      
      The fact that oid columns on system tables are now normal columns
      means that they will be included in the set of columns expanded
      by * (i.e. SELECT * FROM pg_class will now include the table's oid,
      previously it did not). It'd not technically be hard to hide oid
      column by default, but that'd mean confusing behavior would either
      have to be carried forward forever, or it'd cause breakage down the
      line.
      
      While it's not unlikely that further adjustments are needed, the
      scope/invasiveness of the patch makes it worthwhile to get merge this
      now. It's painful to maintain externally, too complicated to commit
      after the code code freeze, and a dependency of a number of other
      patches.
      
      Catversion bump, for obvious reasons.
      
      Author: Andres Freund, with contributions by John Naylor
      Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
      578b2297
  25. 07 Nov, 2018 1 commit
    • Peter Eisentraut's avatar
      pg_upgrade: Allow use of file cloning · 3a769d82
      Peter Eisentraut authored
      Add another transfer mode --clone to pg_upgrade (besides the existing
      --link and the default copy), using special file cloning calls.  This
      makes the file transfer faster and more space efficient, achieving
      speed similar to --link mode without the associated drawbacks.
      
      On Linux, file cloning is supported on Btrfs and XFS (if formatted with
      reflink support).  On macOS, file cloning is supported on APFS.
      Reviewed-by: default avatarMichael Paquier <michael@paquier.xyz>
      3a769d82
  26. 12 Jul, 2018 1 commit
  27. 08 Apr, 2018 1 commit
    • Tom Lane's avatar
      Switch client-side code to include catalog/pg_foo_d.h not pg_foo.h. · 9c0a0de4
      Tom Lane authored
      Everything of use to frontend code should now appear in the _d.h files,
      and making this change frees us from needing to worry about whether the
      catalog header files proper are frontend-safe.
      
      Remove src/interfaces/ecpg/ecpglib/pg_type.h entirely, as the previous
      commit reduced it to a confusingly-named wrapper around pg_type_d.h.
      
      In passing, make test_rls_hooks.c follow project convention of including
      our own files with #include "" not <>.
      
      Discussion: https://postgr.es/m/23690.1523031777@sss.pgh.pa.us
      9c0a0de4
  28. 03 Jan, 2018 1 commit
  29. 16 Nov, 2017 1 commit
  30. 09 Sep, 2017 1 commit
  31. 24 Aug, 2017 1 commit
    • Peter Eisentraut's avatar
      pg_upgrade: Remove dead code · 6ce6a618
      Peter Eisentraut authored
      Remove code meant for upgrading to a particular version of PostgreSQL
      9.0.  Since pg_upgrade only supports upgrading to the current major
      version, this code is no longer useful.
      6ce6a618
  32. 23 Aug, 2017 1 commit
  33. 11 Aug, 2017 1 commit
  34. 14 Jul, 2017 1 commit
  35. 21 Jun, 2017 2 commits
    • Tom Lane's avatar
      Phase 3 of pgindent updates. · 382ceffd
      Tom Lane authored
      Don't move parenthesized lines to the left, even if that means they
      flow past the right margin.
      
      By default, BSD indent lines up statement continuation lines that are
      within parentheses so that they start just to the right of the preceding
      left parenthesis.  However, traditionally, if that resulted in the
      continuation line extending to the right of the desired right margin,
      then indent would push it left just far enough to not overrun the margin,
      if it could do so without making the continuation line start to the left of
      the current statement indent.  That makes for a weird mix of indentations
      unless one has been completely rigid about never violating the 80-column
      limit.
      
      This behavior has been pretty universally panned by Postgres developers.
      Hence, disable it with indent's new -lpl switch, so that parenthesized
      lines are always lined up with the preceding left paren.
      
      This patch is much less interesting than the first round of indent
      changes, but also bulkier, so I thought it best to separate the effects.
      
      Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
      Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
      382ceffd
    • Tom Lane's avatar
      Initial pgindent run with pg_bsd_indent version 2.0. · e3860ffa
      Tom Lane authored
      The new indent version includes numerous fixes thanks to Piotr Stefaniak.
      The main changes visible in this commit are:
      
      * Nicer formatting of function-pointer declarations.
      * No longer unexpectedly removes spaces in expressions using casts,
        sizeof, or offsetof.
      * No longer wants to add a space in "struct structname *varname", as
        well as some similar cases for const- or volatile-qualified pointers.
      * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely.
      * Fixes bug where comments following declarations were sometimes placed
        with no space separating them from the code.
      * Fixes some odd decisions for comments following case labels.
      * Fixes some cases where comments following code were indented to less
        than the expected column 33.
      
      On the less good side, it now tends to put more whitespace around typedef
      names that are not listed in typedefs.list.  This might encourage us to
      put more effort into typedef name collection; it's not really a bug in
      indent itself.
      
      There are more changes coming after this round, having to do with comment
      indentation and alignment of lines appearing within parentheses.  I wanted
      to limit the size of the diffs to something that could be reviewed without
      one's eyes completely glazing over, so it seemed better to split up the
      changes as much as practical.
      
      Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
      Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
      e3860ffa