Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.
Postgres is extensible because its operation is
catalog-driven. If you are familiar with standard
relational systems, you know that they store information
about databases, tables, columns, etc., in what are
commonly known as system catalogs. (Some systems call
this the data dictionary). The catalogs appear to the
user as classes, like any other, but the DBMS stores
its internal bookkeeping in them. One key difference
between Postgres and standard relational systems is
that Postgres stores much more information in its
catalogs -- not only information about tables and columns,
but also information about its types, functions, access
methods, and so on. These classes can be modified by
the user, and since Postgres bases its internal operation
on these classes, this means that Postgres can be
extended by users. By comparison, conventional
database systems can only be extended by changing hardcoded
procedures within the DBMS or by loading modules
specially-written by the DBMS vendor.
Postgres is also unlike most other data managers in
that the server can incorporate user-written code into
itself through dynamic loading. That is, the user can
specify an object code file (e.g., a compiled .o file
or shared library) that implements a new type or function
and Postgres will load it as required. Code written
in SQL are even more trivial to add to the server.
This ability to modify its operation "on the fly" makes
Postgres uniquely suited for rapid prototyping of new
applications and storage structures.
