1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-04 12:42:24 +03:00
Tom Lane 31e5b50292 postgres_fdw: be more wary about shippability of reg* constants.
Don't consider a constant of regconfig or other reg* types to be
shippable unless it refers to a built-in object, or an object in
an extension that's been marked shippable.  Without this
restriction, we're too likely to send a constant that will fail
to parse on the remote server.

For the regconfig type only, consider OIDs up to 16383 to be
"built in", rather than the normal cutoff of 9999.  Otherwise
the initdb-created text search configurations will be considered
unshippable, which is unlikely to make anyone happy.

It's possible that this new restriction will de-optimize queries
that were working satisfactorily before.  Users can restore any
lost performance by making sure that objects that can be expected
to exist on the remote side are in shippable extensions.  However,
that's not a change that people are likely to be happy about having
to make after a minor-release update.  Between that consideration
and the lack of field complaints, let's just change this in HEAD.

Noted while fixing bug #17483, although this is not precisely
the problem that that report complained about.

Discussion: https://postgr.es/m/1423433.1652722406@sss.pgh.pa.us
2022-07-17 18:11:22 -04:00
..
2022-01-07 19:04:57 -05:00
2022-01-07 19:04:57 -05:00
2022-01-07 19:04:57 -05:00
2022-01-07 19:04:57 -05:00
2022-01-07 19:04:57 -05:00
2022-05-13 07:17:29 +02:00
2022-01-07 19:04:57 -05:00
2022-01-07 19:04:57 -05:00
2022-01-07 19:04:57 -05:00
2022-04-08 00:26:44 -07:00

The PostgreSQL contrib tree
---------------------------

This subtree contains porting tools, analysis utilities, and plug-in
features that are not part of the core PostgreSQL system, mainly
because they address a limited audience or are too experimental to be
part of the main source tree.  This does not preclude their
usefulness.

User documentation for each module appears in the main SGML
documentation.

When building from the source distribution, these modules are not
built automatically, unless you build the "world" target.  You can
also build and install them all by running "make all" and "make
install" in this directory; or to build and install just one selected
module, do the same in that module's subdirectory.

Some directories supply new user-defined functions, operators, or
types.  To make use of one of these modules, after you have installed
the code you need to register the new SQL objects in the database
system by executing a CREATE EXTENSION command.  In a fresh database,
you can simply do

    CREATE EXTENSION module_name;

See the PostgreSQL documentation for more information about this
procedure.