Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

tablespace.c

Blame
    • Heikki Linnakangas's avatar
      a5782570
      Accept a non-existent value in "ALTER USER/DATABASE SET ..." command. · a5782570
      Heikki Linnakangas authored
      When default_text_search_config, default_tablespace, or temp_tablespaces
      setting is set per-user or per-database, with an "ALTER USER/DATABASE SET
      ..." statement, don't throw an error if the text search configuration or
      tablespace does not exist. In case of text search configuration, even if
      it doesn't exist in the current database, it might exist in another
      database, where the setting is intended to have its effect. This behavior
      is now the same as search_path's.
      
      Tablespaces are cluster-wide, so the same argument doesn't hold for
      tablespaces, but there's a problem with pg_dumpall: it dumps "ALTER USER
      SET ..." statements before the "CREATE TABLESPACE" statements. Arguably
      that's pg_dumpall's fault - it should dump the statements in such an order
      that the tablespace is created first and then the "ALTER USER SET
      default_tablespace ..." statements after that - but it seems better to be
      consistent with search_path and default_text_search_config anyway. Besides,
      you could still create a dump that throws an error, by creating the
      tablespace, running "ALTER USER SET default_tablespace", then dropping the
      tablespace and running pg_dumpall on that.
      
      Backpatch to all supported versions.
      a5782570
      History
      Accept a non-existent value in "ALTER USER/DATABASE SET ..." command.
      Heikki Linnakangas authored
      When default_text_search_config, default_tablespace, or temp_tablespaces
      setting is set per-user or per-database, with an "ALTER USER/DATABASE SET
      ..." statement, don't throw an error if the text search configuration or
      tablespace does not exist. In case of text search configuration, even if
      it doesn't exist in the current database, it might exist in another
      database, where the setting is intended to have its effect. This behavior
      is now the same as search_path's.
      
      Tablespaces are cluster-wide, so the same argument doesn't hold for
      tablespaces, but there's a problem with pg_dumpall: it dumps "ALTER USER
      SET ..." statements before the "CREATE TABLESPACE" statements. Arguably
      that's pg_dumpall's fault - it should dump the statements in such an order
      that the tablespace is created first and then the "ALTER USER SET
      default_tablespace ..." statements after that - but it seems better to be
      consistent with search_path and default_text_search_config anyway. Besides,
      you could still create a dump that throws an error, by creating the
      tablespace, running "ALTER USER SET default_tablespace", then dropping the
      tablespace and running pg_dumpall on that.
      
      Backpatch to all supported versions.