nyuuzyou/wikis huggingface dataset:
AllComputers

A place to note code being dropped because there are no relevant systems left that don't implement a standard feature we need.
* all computers have getaddrinfo(): 
* all computers have AF_UNIX sockets: , 
* all computers have AF_INET6 sockets: 
* all computers have sockaddr_storage: 
* all computers have 4.3BSD style socket API (no need for explicit handling of 4.4BSD _len extensions): 
* all computers have <wctype.h>: 
* all computers have <wchar.h>: 
* all computers have utime(): 
* all computers have threads: 
* all computers have locale_t: 
* all computers have a way to implement spinlocks: 
* all computers have a way to implement 32 bit atomics: 
* all computers have a way to implement compiler barriers: 
* all computers have a way to implement memory barriers: 
* all POSIX computers have "System V" shared memory and semaphores: 
* all POSIX computers have "POSIX" shared memory: 
* all POSIX computers have basic vector I/O: 
* all POSIX computers have getrusage(): , 
* all POSIX computers have sigwait(): 
* all POSIX computers have dlopen(): 
* all POSIX computers have getpwuid_r(): 
* all POSIX computers have select(): 
* all POSIX computers have setenv() and unsetenv(): 
* all POSIX computers have poll(): 
* all POSIX computers have fdatasync(): 
* all POSIX computers have clock_gettime(): 
* all POSIX computers have pread() and pwrite(): 
* all POSIX computers have link(): 
* all POSIX computers have symlinks: 
* all POSIX computers have setsid(): 
* all POSIX computers have getrlimit(): 
* all POSIX computers have F_SETFD and FD_CLOEXEC: 
* all POSIX computers have O_SYNC: 
* all POSIX computers have sigprocmask(): 
* all POSIX computers have <langinfo.h>: 
* all POSIX computers have CODESET: 
* all POSIX computers have nl_langinfo_l(): 
Future work:
* all computers have large file support
* all computers have C++ (cfront wasn't considered stable enough in 1985, so the "node" inheritance system was made as a stand-in for later transmogrification into C++)
Alpha release notes draft

The third alpha release for PostgreSQL version 9.1, 9.1alpha3, is now
available. This alpha release contains several new major features added
since the alpha2 release. Please download, install, and test it to give
us early feedback on the features being developed for the future
versions of PostgreSQL.
Features added in 9.1alpha3 since alpha2 include:
* KNNGiST, which implements order-by-operator support for GiST and optimizes nearest-neighbor geographic searches. This will power the next release of PostGIS.
* Additional instrumentation and monitoring facilities, including checkpoint introspection and last-WAL-timestamp information for replication.
* Several new built-in functions: format(), pg_read_binary_file(), pg_describe_object(), pg_execute_from_file(), many of which will support the Extensions feature.
* New libpq functions: PQping(), PQlibVersion()
* The capability to produce crash dumps on Windows
* New auth_delay module to introduce a delay on failed authentications and make dictionary attacks more difficult. 
* Security hooks on object creation, to support SEPostgres.
More detail is available in the release notes:
http://developer.postgresql.org/pgdocs/postgres/release-9-1-alpha.html
These new features mean that we need you to participate in testing them.
If you are able to help with organized alpha testing, please see the
Alpha/Beta testing page: http://wiki.postgresql.org/wiki/HowToBetaTest
Alpha releases are not stable and should never be used in production;
they are for testing new features only. There is no guarantee that any
features or APIs present in the alphas will be present, or the same, in
the final release.
Alpha release information page:
http://www.postgresql.org/developer/alpha
Download the alpha release here:
http://www.postgresql.org/ftp/source/v9.1alpha3/
Alpha releases are primarily made in source code form only. Binary
packages for some operating systems will be prepared in the coming days.
Category:Release notes
Category:PostgreSQL 9.1
Alpha release process

== Prerequisites ==
* Commit fest manager declares commit fest closed
* Build farm status is green, or failures are adequately explained (if widespread breakage, wait for a few days until fixed)
== Naming ==
* 8.5alpha1, 8.5alpha2, etc.
== Release preparation ==
In general, src/tools/RELEASE_CHANGES applies. Exact procedure for alpha releases:
# Release notes [discussion]
# Optional: Update timezone data
# Optional: Translation updates (probably not useful for the first or second alpha)
# Note down the SHA1 of the head commit, don't tag yet.
# Export the tree, e.g.: mkdir ../export; git archive SHA1 | tar -C ../export -x -f -; cd ../export (Steps from here on should be done on developer.postgresql.org, so we get for example a consistent flex version.)
# Release version number changes, e.g,.: src/tools/version_stamp.pl alpha2
# autoconf (on developer.postgresql.org, see ~petere/sw/ac263 for the appropriate autoconf version)
# ./configure
# Build the actual release tarball: make distcheck
# Create md5 sum files: md5 filename > filename.md5
# Ask -hackers to check the tarball for sanity
# Upload to ftp server (under ~ftp on developer.postgresql.org)
# When the release is final, tag the SHA1: git tag REL9_1_ALPHA2; and push the tag.
Note: Per PGCon 2010 discussion, beginning with 9.1, we will no longer make a branch for each alpha release just to make the version number changes.
Note: It is very important not to introduce any stray files into the working tree created when you export the Git tree. 'make distcheck' is not too smart and may incorporate such files into the release tarball.
== Announcing ==
Update web page: http://www.postgresql.org/developer/alpha
Announce to:
* PostgreSQL News
* pgsql-announce
For this one, we don't wait for the binaries to be built before announcing. Just make sure that the source tarballs are in place before the announcements go out. This may take a day or three; doesn't really matter.
ReleasePrep contains notes about how to announce a release, which do not apply in their entirety to the alpha process, but are still worth digesting.
Category:PostgreSQL 9.0
ALTER AGGREGATE

===== 名字 =====
ALTER AGGREGATE -- 修改一个聚集函数的定义
===== 语法概要 =====
 ALTER AGGREGATE name ( type [ , ... ] ) RENAME TO new_name
 ALTER AGGREGATE name ( type [ , ... ] ) OWNER TO new_owner
 ALTER AGGREGATE name ( type [ , ... ] ) SET SCHEMA new_schema
===== 描述 =====
ALTER AGGREGATE 改变一个聚集函数的定义。 
要使用 ALTER AGGREGATE，你必须是该聚集函数的所有者。 要改变这个聚集函数的模式，你同时必须在更新的模式上具有 CREATE 权限。 要改变这个聚集函数的所有者，你同时也必须是更新的所有者角色的一个直接或者间接成员， 并且该角色必须在这个聚集函数的模式上具有 CREATE 权限。 （这强制限制在进行更改函数所有者的操作时，如果无法通过删除后重建的方式完成，那么就不能做任何事。 不过，超级用户可以用任何方法任意更改聚集函数的所有者。）
===== 参数 =====
;name
:一个现有的聚集函数的名字（可以有模式修饰）。
;type
:聚集函数操作的输入数据的数据类型。要表示某个0个参数的聚集函数，在输入类型列表中添 *。
;new_name
:聚集函数的新名字。
;new_owner
:聚集函数的新所有者。
;new_schema
:聚集函数的新模式。
===== 示例 =====
把对 integer 类型进行聚集操作的 myavg 函数重命名为 my_average：To rename the aggregate function myavg for type integer to my_average:
 ALTER AGGREGATE myavg(integer) RENAME TO my_average;
把对 integer 类型进行聚集操作的 myavg 函数的所有者变更为 joe：To change the owner of the aggregate function myavg for type integer to joe:
 ALTER AGGREGATE myavg(integer) OWNER TO joe;
把对 integer 类型进行聚集操作的 myavg 函数移动到模式 myschema 里：To move the aggregate function myavg for type integer into schema myschema:
 ALTER AGGREGATE myavg(integer) SET SCHEMA myschema;
===== 兼容性 =====
SQL 标准里面没有 ALTER AGGREGATE 语句。
===== 参见 =====
CREATE AGGREGATE, DROP AGGREGATE
ALTER COLLATION

===== 名字 =====
ALTER COLLATION -- 修改字符序的定义
===== 语法概要 =====
 ALTER COLLATION name RENAME TO new_name
 ALTER COLLATION name OWNER TO new_owner
 ALTER COLLATION name SET SCHEMA new_schema
===== 描述 =====
ALTER COLLATION 修改字符序的定义。
为了应用 ALTER COLLATION 命令，你必须对字符序具有所有权。为了改变字符序的所有权，你必须是新角色的直接或间接成员，并且这个新角色必须具有该字符序上模式的 CREATE 权限。（这强制限制在进行更改字符序所有者的操作时，如果无法通过删除后重建的方式完成，那么就不能做任何事。 不过，超级用户可以用任何方法任意更改字符序的所有者。）
===== 参数 =====
;name
:一个现有的字符序的名字（可以有模式修饰）。
;new_name
:字符序的新名字。
;new_owner
:字符序的新所有者。
;new_schema
:字符序的新模式。
===== 示例 =====
将字符序 de_DE 重命名为 german:
 ALTER COLLATION "de_DE" RENAME TO german;
将字符序 en_US 的所有者变更为 joe
 ALTER COLLATION "en_US" OWNER TO joe;
===== 兼容性 =====
SQL 标准里面没有 ALTER COLLATION 语句。
===== 参见=====
CREATE COLLATION, DROP COLLATION
ALTER CONVERSION

=====名字=====
ALTER CONVERSION --修改一个编码转换的定义
=====语法概要=====
 ALTER CONVERSION name RENAME TO new_name
 ALTER CONVERSION name OWNER TO new_owner
 ALTER CONVERSION name SET SCHEMA new_schema
=====描述=====
ALTER CONVERSION 修改一个编码转换的定义。
为了应用 ALTER CONVERSION 命令，你必须对该编码转换具有所有权。 要改变编码转换的所有权，你必须是新角色的直接或间接成员，并且这个新角色必须具有该转换上模式的 CREATE 权限。（这强制限制在进行更改编码转换所有者的操作时，如果无法通过删除后重建的方式完成，那么就不能做任何事。不过，超级用户可以用任何方法任意更改编码转换的所有者。）
=====参数=====
;name
:一个现有的编码转换的名字（可以有模式修饰）。
;new_name
:编码转换的新名字。
;new_owner
:编码转换的新所有者。
;new_schema
:编码转换的新模式。
=====示例=====
把编码转换 iso_8859_1_to_utf8 重新命名为 latin1_to_unicode:
 ALTER CONVERSION iso_8859_1_to_utf8 RENAME TO latin1_to_unicode;
把编码转换 iso_8859_1_to_utf8 的所有者改变为 joe:
 ALTER CONVERSION iso_8859_1_to_utf8 OWNER TO joe;
=====兼容性=====
SQL标准里没有ALTER CONVERSION语句。
=====参见=====
CREATE CONVERSION, DROP CONVERSION
ALTER DATABASE

=====名字=====
ALTER DATABASE -- 修改一个数据库
=====语法概要=====
 ALTER DATABASE name [ [ WITH ] option [ ... ] ]
 
 where option can be:
 
 CONNECTION LIMIT connlimit
 
 ALTER DATABASE name RENAME TO new_name
 
 ALTER DATABASE name OWNER TO new_owner
 
 ALTER DATABASE name SET TABLESPACE new_tablespace
 
 ALTER DATABASE name SET configuration_parameter { TO | = } { value | DEFAULT }
 ALTER DATABASE name SET configuration_parameter FROM CURRENT
 ALTER DATABASE name RESET configuration_parameter
 ALTER DATABASE name RESET ALL
=====描述=====
ALTER DATABASE 改变一个数据库的属性。
第一种命令形式修改数据库各自的设置。（见下文获取细节。） 只有数据库所有者或者超级用户可以改变这些设置。
第二种命令形式修改数据库名字。只有数据库所有者或者超级用户可以重命名一个数据库；非超级用户必须拥有 CREATEDB 权限。 当前的数据库不能被重命名。（如果你需要这么做，那么连接至另外一个数据库。）
第三种命令形式修改数据库的所有者。要改变所有者，你必须已经是该数据库的所有者并且是新的所有权角色的直接或者间接成员， 并且还必须有 CREATEDB 权限。（请注意，超级用户自动拥有所有这些权限。）
第四种命令形式修改数据库的缺省表空间。只有数据库所有者或超级用户可以这样做；你也必须在新的表空间中具备create权限。这条命令物理上将数据库的所有表和索引从原先的表空间移动到新的表空间。值得注意的是，这个操作对非缺省表空间中的表和索引并不起作用。
其余的命令形式修改 PostgreSQL 数据库会话缺省的运行时配置变量。 一旦变量修改，建立新会话的时候就会使用这些修改后的值作为缺省值。数据库特定设置的优先级比在postgresql.conf中进行的或从postgres命令行接收的设置更高，前者会覆盖后两者。只有数据库所有者或者超级用户可以改变会话的缺省设置。有些变量不能用这种方法设置，或者是只能由超级用户设置。
=====参数=====
;name
:需要修改属性的数据库的名字。
;connlimit
:对这个数据库可以做多少个并发连接。-1 意味着没有限制。
;new_name
:数据库的新名字。
;new_owner
:数据库的新所有者。
;new_tablespace
:数据库的新缺省表空间。
;configuration_parameter
;value
:将configuration_parameter指定的数据库会话缺省参数设置为给定值value。如果 value 是 DEFAULT 或者是等效的 RESET，那么数据库特定的设置将被删除，因此在新的会话中将使用系统范围的缺省设置。 用 RESET ALL 清除所有数据库特定设置。SET FROM CURRENT将会话的当前缺省值设置为数据库特定值。
:参阅 SET 和 第 18 章获取有关合法的变量名与取值的更多信息。
=====注意=====
我们也可以把一个会话缺省设置绑定到一个特定角色，而不是某个数据库上； 参阅 [ALTER ROLE]。如果存在冲突，那么角色特定设置的优先级高于数据库特定的设置，将之覆盖。
=====示例=====
禁用数据库 test 上缺省启用的索引扫描功能∶
 ALTER DATABASE test SET enable_indexscan TO off;
=====兼容性=====
ALTER DATABASE语句是PostgreSQL的扩展。
=====参见=====
CREATE DATABASE, DROP DATABASE, SET, CREATE TABLESPACE
ALTER DEFAULT PRIVILEGES

=====名字=====
ALTER DEFAULT PRIVILEGES -- 定义缺省访问权限
=====语法概要=====
 ALTER DEFAULT PRIVILEGES
 [ FOR { ROLE | USER } target_role [, ...] ]
 [ IN SCHEMA schema_name [, ...] ]
 abbreviated_grant_or_revoke
 
 where abbreviated_grant_or_revoke is one of:
 
 GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
 [, ...] | ALL [ PRIVILEGES ] }
 ON TABLES
 TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
 
 GRANT { { USAGE | SELECT | UPDATE }
 [, ...] | ALL [ PRIVILEGES ] }
 ON SEQUENCES
 TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
 
 GRANT { EXECUTE | ALL [ PRIVILEGES ] }
 ON FUNCTIONS
 TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
 
 REVOKE [ GRANT OPTION FOR ]
 { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
 [, ...] | ALL [ PRIVILEGES ] }
 ON TABLES
 FROM { [ GROUP ] role_name | PUBLIC } [, ...]
 [ CASCADE | RESTRICT ]
 
 REVOKE [ GRANT OPTION FOR ]
 { { USAGE | SELECT | UPDATE }
 [, ...] | ALL [ PRIVILEGES ] }
 ON SEQUENCES
 FROM { [ GROUP ] role_name | PUBLIC } [, ...]
 [ CASCADE | RESTRICT ]
 
 REVOKE [ GRANT OPTION FOR ]
 { EXECUTE | ALL [ PRIVILEGES ] }
 ON FUNCTIONS
 FROM { [ GROUP ] role_name | PUBLIC } [, ...]
 [ CASCADE | RESTRICT ]
=====描述=====
ALTER DEFAULT PRIVILEGES 命令修改对象权限，执行之后所创建的对象都将使用这个权限。（这个操作不会影响已赋予权限的已有对象。）目前，只有表（包括视图和外部表）、 序列和函数的权限可以更改。
你可以为你自己或你所具备的角色将要创建的对象更改缺省权限。权限可以设置为全局的 （例如：在当前数据库中创建的所有对象），或者仅仅针对特定模式中的对象设置。 每个模式特定的缺省权限被合并到特定对象类型的全局缺省权限中。
正如 GRANT 表述的，一般来说，任意对象类型的缺省权限会为对象的所有者授予所有可赋予的权限，同时可能也会向 PUBLIC 授予一些权限。 然而，这个默认行为可以通过 ALTER DEFAULT PRIVILEGES 改变全局缺省权限来改变。
=====参数=====
;target_role
:已有角色的名称，当前角色需要是这个角色的成员。如果没有指定 FOR ROLE，那么就假定是当前角色。
;schema_name
:现有模式的名称。每个 'target_role' 必须在每个指定的模式上具有 CREATE权限。如果没有指定 IN SCHEMA，那么被修改的会是全局缺省权限。
;role_name
:被授予或者撤消权限的现有角色的名称。该参数和'abbreviated_grant_or_revoke'参数集下的所有参数，与 GRANT 和 REVOKE 命令中的作用相似，所不同的是这里设置的是某一类所有对象的权限，而不是设置某个特定命名对象的权限。
=====注意=====
使用 psql 的 \ddp 命令可以获取缺省权限的已分配信息。权限取值的含义与 GRANT 下的 \dp的解释相同。
如果您想删除一个角色而这个角色已经修改过默认权限设置，要么就恢复哪些已经修改的默认权限，要么使用 DROP OWNED BY 命令来清除角色所具备的缺省权限。
=====示例=====
为所有用户在模式myschema接下来所创建的所有表（和视图）授予SELECT权限，同时授予角色 webuser INSERT权限：
 ALTER DEFAULT PRIVILEGES IN SCHEMA myschema GRANT SELECT ON TABLES TO PUBLIC;
 ALTER DEFAULT PRIVILEGES IN SCHEMA myschema GRANT INSERT ON TABLES TO webuser;
撤销上述授权，所以随后创建的表所具有的权限比普通权限没有额外的权限：
 ALTER DEFAULT PRIVILEGES IN SCHEMA myschema REVOKE SELECT ON TABLES FROM PUBLIC;
 ALTER DEFAULT PRIVILEGES IN SCHEMA myschema REVOKE INSERT ON TABLES FROM webuser;
对随后角色admin创建的所有函数，撤销其在PUBLIC上的EXECUTE权限（一般情况下是授予的）：
 ALTER DEFAULT PRIVILEGES FOR ROLE admin REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
=====兼容性=====
SQL标准里没有 ALTER DEFAULT PRIVILEGES 语句。
=====参见=====
GRANT, REVOKE
ALTER DOMAIN

=====名字=====
ALTER DOMAIN -- 修改一个域的定义
=====语法概要=====
 ALTER DOMAIN name
 { SET DEFAULT expression | DROP DEFAULT }
 ALTER DOMAIN name
 { SET | DROP } NOT NULL
 ALTER DOMAIN name
 ADD domain_constraint
 ALTER DOMAIN name
 DROP CONSTRAINT constraint_name [ RESTRICT | CASCADE ]
 ALTER DOMAIN name
 OWNER TO new_owner 
 ALTER DOMAIN name
 SET SCHEMA new_schema
===== 描述=====
ALTER DOMAIN 修改一个现有域的定义。它有几种子形式：
;SET/DROP DEFAULT
:这些子形式为一个域设置或者删除缺省值。请注意缺省值仅可用于随后的INSERT命令； 命令不影响表中已有行所使用的域。
;SET/DROP NOT NULL
:这些子形式改变一个域是否标记为允许NULL值或者是拒绝NULL值。在使用域的字段包含非NULL值的时候， 你只可以SET NOT NULL。
;ADD domain_constraint
:这个子形式使用和CREATE DOMAIN一样的语法向域中增加一种新的约束。 这样做只有在所有使用域的字段满足新约束的条件下才能成功。
;DROP CONSTRAINT
:这种形式删除一个域上的约束。
;OWNER
:这种形式把域的所有者改变为另外一个用户。
;SET SCHEMA
:这个形式改变域的模式。任何与该域相关的约束都移动到新的模式里。
要使用ALTER DOMAIN，您必须具有域的所有权。要修改一个域的模式， 您还必须在新模式上拥有CREATE权限。要修改所有者， 您还必须是新的所有角色的直接或间接成员，并且该成员必须在此域的模式上有CREATE权限。（这强制限制在进行更改所有者的操作时，如果无法通过删除后重建域的方式完成，那么就不能做任何事。 不过，超级用户可以用任何方法任意更改域的所有者。）
=====参数=====
;name
:一个要修改的现有域的名字(可以有模式修饰)。
;domain_constraint
:域的新域约束
;constraint_name
:要删除的旧有约束
;CASCADE
:级联删除依赖这个对象的约束
;RESTRICT
:如果有任何依赖对象，则拒绝删除约束。这是缺省行为。
;new_owner
:域的新所有者的用户名
;new_schema
:域的新模式
=====注意=====
目前，如果命名的域或者任何派生的域用于数据库所有表的一个复合列中，那么 ALTER DOMAIN ADD CONSTRAINT和ALTER DOMAIN SET NOT NULL 将失败。最终，他们应该加以改进以达到能够验证这种嵌套列的新约束。
=====示例=====
给一个域增加一个NOT NULL约束：
 ALTER DOMAIN zipcode SET NOT NULL;
从一个域里删除一个NOT NULL约束：
 ALTER DOMAIN zipcode DROP NOT NULL;
向一个域里增加一个检查约束：
 ALTER DOMAIN zipcode ADD CONSTRAINT zipchk CHECK (char_length(VALUE) = 5);
从一个域里删除一个检查约束：
 ALTER DOMAIN zipcode DROP CONSTRAINT zipchk;
把域移动到另外一个模式：
 ALTER DOMAIN zipcode SET SCHEMA customers;
=====兼容性=====
除OWNER和SET SCHEMA变种是PostgreSQL扩展之外， ALTER DOMAIN语句与SQL标准兼容。
=====参见=====
CREATE DOMAIN, DROP DOMAIN
ALTER EXTENSION

=====名字=====
ALTER EXTENSION -- 修改一个扩展的定义
=====语法概要=====
 ALTER EXTENSION extension_name UPDATE [ TO new_version ]
 ALTER EXTENSION extension_name SET SCHEMA new_schema
 ALTER EXTENSION extension_name ADD member_object
 ALTER EXTENSION extension_name DROP member_object
 
 where member_object is:
 
 AGGREGATE agg_name (agg_type [, ...] ) |
 CAST (source_type AS target_type) |
 COLLATION object_name |
 CONVERSION object_name |
 DOMAIN object_name |
 FOREIGN DATA WRAPPER object_name |
 FOREIGN TABLE object_name |
 FUNCTION function_name ( [ [ argmode ] [ argname ] argtype [, ...] ] ) |
 OPERATOR operator_name (left_type, right_type) |
 OPERATOR CLASS object_name USING index_method |
 OPERATOR FAMILY object_name USING index_method |
 [ PROCEDURAL ] LANGUAGE object_name |
 SCHEMA object_name |
 SEQUENCE object_name |
 SERVER object_name |
 TABLE object_name |
 TEXT SEARCH CONFIGURATION object_name |
 TEXT SEARCH DICTIONARY object_name |
 TEXT SEARCH PARSER object_name |
 TEXT SEARCH TEMPLATE object_name |
 TYPE object_name |
 VIEW object_name
=====描述=====
ALTER EXTENSION 改变一个已经安装的扩展的定义。有以下几种形式：
;UPDATE
:这个形式将扩展升级至新版本。扩展必须提供一个（或几个）可以将当前已安装版本修改至新版本的脚本。
;SET SCHEMA
:这个形式将扩展的对象移动到另一个模式中去。要成功执行这个命令，扩展需是可重定位的。
;ADD member_object
:这个形式将一个已有对象添加进扩展。该形式在扩展升级脚本中非常有用。添加之后对象被作为扩展的一个成员；值得注意的是，要丢弃这个对象的话，只能丢弃整个扩展。
;DROP member_object
:这个形式将成员对象从扩展中移除。该形式在扩展升级脚本中非常有用。该对象并没有被丢弃，只是从扩展中移除出去。
关于这些操作的更多信息可以参见35.15节。
你必须具有扩展的所有权才能执行ALTER EXTENSION命令。ADD/DROP命令需要被添加或移除对象的所有权。
=====参数=====
;extension_name
:已装扩展的名字。
;new_version
:扩展希望升至的新版本。这个参数可以是一个标示符也可以是字符串字面量。如果没有指定这个参数，ALTER EXTENSION UPDATE 将扩展升级至扩展控制文件中指定的缺省版本。
;new_schema
:扩展的新模式。
;object_name
;agg_name
;function_name
;operator_name
:扩展将要添加或移除的对象的名字。表，聚集函数，域，外部表，函数，操作符，操作符类，操作符族，序列，文本检索对象，类型，视图等对象的名字，可以用模式修饰。 
;agg_type
:聚集函数操作的输入数据的数据类型。要表示某个0个参数的聚集函数，在输入类型列表中添 * 。
;source_type
:强制类型转换的源数据类型。
;target_type
:强制类型转换的目标数据类型。
;argmode
:函数参数的模式：IN，OUT，INOUT，VARIADIC。如果不指定该参数，默认为IN。注意，ALTER EXTENSION实际上不会处理OUT模式的参数，因为只有输入参数才会作为函数签名的一部分来标识函数实体。因此，列出IN，INOUT，VARIDIC模式就足够了。
;argname
:函数参数的名字。注意，ALTER EXTENSION实际上不会处理参数名字，因为只有参数的数据类型才会作为函数的签名的一部分来标识函数实体。
;argtype
:函数参数的数据类型，如果有模式的话可以使用模式进行修饰。
;left_type
;right_type
:操作符的数据类型，可以使用模式进行修饰。前缀或后缀操作符对应（左和右）的缺少部分应该添NONE。
;PROCEDURAL
:这个参数没必要存在。
=====示例=====
将hstore扩展升级至2.0版：
 ALTER EXTENSION hstore UPDATE TO '2.0';
将hstore扩展的模式改为utils：
 ALTER EXTENSION hstore SET SCHEMA utils;
将一个已有函数添加进hstore扩展：
 ALTER EXTENSION hstore ADD FUNCTION populate_record(anyelement, hstore);
=====兼容性=====
ALTER EXTENSION 是PostgreSQL扩展。
=====参见=====
CREATE EXTENSION, DROP EXTENSION
ALTER FOREIGN DATA WRAPPER

=====名字=====
ALTER FOREIGN DATA WRAPPER -- 修改一个外部数据封装的定义
=====语法概要=====
 ALTER FOREIGN DATA WRAPPER name
 [ HANDLER handler_function | NO HANDLER ]
 [ VALIDATOR validator_function | NO VALIDATOR ]
 [ OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ]) ]
 ALTER FOREIGN DATA WRAPPER name OWNER TO new_owner
=====描述=====
ALTER FOREIGN DATA WRAPPER 改变外部数据封装的定义。第一种形式的命令修改外部数据封装的支撑函数或通用选项（至少需要一个子句）。第二种形式的命令修改外部数据封装的所有者。
只有超级用户才能更改外部数据封装。甚至，只有超级用户才能拥有外部数据封装。
=====参数=====
;name
:已有外部数据封装的名字。
;HANDLER handler_function
:指定一个外部数据封装的新句柄函数。
;NO HANDLER
:设置外部数据封装不再具有句柄函数。
:注意，使用外部数据封装的外部表如果没有处理句柄的话，就不可以被访问。
;VALIDATOR validator_function
:设置外部数据封装的新验证函数。
:注意，可能会出现这种情况：更改验证函数之后，外部的数据封装，外部服务器和外部用户映射都变的不可用。在使用外部数据封装之前确保这些参数的正确性是用户的责任。 
;NO VALIDATOR
:设置外部数据封装不再具有验证函数。
;OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ] )
:改变外部数据封装的选项。ADD, SET, 和 DROP设置需要执行的操作。如果没有显示设置，那么默认进行ADD操作。选项名字必须唯一；如果有验证函数，名字和值会通过验证函数进行验证。
=====示例=====
修改外部数据封装dbi，add option foo, drop bar：
 ALTER FOREIGN DATA WRAPPER dbi OPTIONS (ADD foo '1', DROP 'bar');
修改外部数据封装dbi的验证函数为bob.myvalidator：
 ALTER FOREIGN DATA WRAPPER dbi VALIDATOR bob.myvalidator;
=====兼容性=====
除了HANDLER, VALIDATOR 和 OWNER TO 子句是PostgreSQL扩展之外，ALTER FOREIGN DATA WRAPPER 符合 ISO/IEC 9075-9 (SQL/MED) 标准。
=====参见=====
CREATE FOREIGN DATA WRAPPER, DROP FOREIGN DATA WRAPPER
ALTER FOREIGN TABLE

=====名称=====
ALTER FOREIGN TABLE -- 修改一个外部表的定义
=====语法概要=====
 ALTER FOREIGN TABLE name
 action [, ... ]
 ALTER FOREIGN TABLE name
 RENAME [ COLUMN ] column TO new_column
 ALTER FOREIGN TABLE name
 RENAME TO new_name
 ALTER FOREIGN TABLE name
 SET SCHEMA new_schema
 
 where action is one of:
 
 ADD [ COLUMN ] column type [ NULL | NOT NULL ]
 DROP [ COLUMN ] [ IF EXISTS ] column [ RESTRICT | CASCADE ]
 ALTER [ COLUMN ] column [ SET DATA ] TYPE type
 ALTER [ COLUMN ] column { SET | DROP } NOT NULL
 OWNER TO new_owner
 OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ])
=====描述=====
ALTER FOREIGN TABLE 修改一个外部表的定义。有以下几种形式：
;ADD COLUMN
:这个形式向外部表中添加一个新列，语法同CREATE FOREIGN TABLE.
;DROP COLUMN [ IF EXISTS ]
:这个形式从外部表中丢弃一个列。如果表中的该数据列被其他地方依赖，那就需要CASCADE；比如依赖该数据列的视图。如果指定的有 IF EXISTS 字句，则在数据列不存在时也不会报错，只是会发出一个通告。
;SET DATA TYPE
:这个形式修改外部表数据列的类型。
;SET/DROP NOT NULL
:允许或禁止数据列可以存为null值。
;OWNER
:这个形式将外部表的所有者修改成另一个用户。
;RENAME
:修改外部表的名字，或者外部表内部单独某个数据列的名字。
;SET SCHEMA
:这个形式将外部表移动到另一个模式中。
;OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ] )
:改变外部表的选项。ADD, SET, 和DROP 指定执行的操作。如果没有显示设置操作，那么默认就是ADD。 选项名字必须唯一；名字和值也都会通过外部数据封装库进行验证。
除 RENAME 和SET SCHEMA 之外的操作都可以写在组合在一起，一次执行多个操作。例如，在单一一条命令中，可以添加多个列和（或者）修改多个列的数据类型。
你必须是表的所有者才能使用 ALTER FOREIGN TABLE 命令。要修改外部表的模式，必须在被修改的新模式中拥有CREATE权限。要改变外部表的所有权，你必须是新角色的直接或间接成员，并且这个新角色必须在该表的模式上具有 CREATE 权限。（这强制限制在进行更改所有者的操作时，如果无法通过删除后重建表的方式完成，那么就不能做任何事。不过，超级用户可以用任何方法任意更改表的所有者。）
=====参数=====
;name
:要修改的已有外部表的名字（可以有模式修饰）。
;column
:新建或已有数据列名称。
;new_column
:已有数据列的新名字。
;new_name
:表的新名字。
;type
:新数据列的数据类型，或者已有数据列的新类型。
;CASCADE
:丢弃数据列的同时自动丢弃那些依赖该列的对象（例如引用该列的视图）。
;RESTRICT
:如果有该列的依赖存在，就拒绝丢弃该列。这是默认行为。
;new_owner
:表的新所有者的用户名。
;new_schema
:被移动表进来的模式名称。
=====注意=====
关键字 COLUMN 没用，可以被忽略。
列通过ADD COLUMN和DROP COLUMN进行添加或修改，通过添加NOT NULL进行约束，或通过SET DATA TYPE改变数据类型之后，不会检查数据一致性。确保表定义和远端表定义相匹配是用户的责任。
参见CREATE FOREIGN TABLE关于可用参数的更多信息。 
=====示例=====
设置数据列为 not-null：
 ALTER FOREIGN TABLE distributors ALTER COLUMN street SET NOT NULL;
修改外部表的选项：
 ALTER FOREIGN TABLE myschema.distributors OPTIONS (ADD opt1 'value', SET opt2, 'value2', DROP opt3 'value3');
=====兼容性=====
ADD，DROP 和 SET DATA TYPE 这三种形式符合SQL标准。其他形式是PostgreSQL的扩展。另外，一个ALTER FOREIGN TABLE命令中设置多个操作的能力也是扩展。
ALTER FOREIGN TABLE DROP COLUMN 可以删除外部表中的仅有的唯一一个列，删除之后就是一个无数据列的表。这个特性是PostgreSQL的扩展，标准SQL中不允许无数据列的表。