mirror of
https://github.com/postgres/postgres.git
synced 2025-12-21 05:21:08 +03:00
Move test modules from contrib to src/test/modules
This is advance preparation for introducing even more test modules; the easy solution is to add them to contrib, but that's bloated enough that it seems a good time to think of something different. Moved modules are dummy_seclabel, test_shm_mq, test_parser and worker_spi. (test_decoding was also a candidate, but there was too much opposition to moving that one. We can always reconsider later.)
This commit is contained in:
@@ -113,7 +113,6 @@ CREATE EXTENSION <replaceable>module_name</> FROM unpackaged;
|
||||
&dblink;
|
||||
&dict-int;
|
||||
&dict-xsyn;
|
||||
&dummy-seclabel;
|
||||
&earthdistance;
|
||||
&file-fdw;
|
||||
&fuzzystrmatch;
|
||||
@@ -141,8 +140,6 @@ CREATE EXTENSION <replaceable>module_name</> FROM unpackaged;
|
||||
&tablefunc;
|
||||
&tcn;
|
||||
&test-decoding;
|
||||
&test-parser;
|
||||
&test-shm-mq;
|
||||
&tsearch2;
|
||||
&unaccent;
|
||||
&uuid-ossp;
|
||||
|
||||
@@ -1,74 +0,0 @@
|
||||
<!-- doc/src/sgml/dummy-seclabel.sgml -->
|
||||
|
||||
<sect1 id="dummy-seclabel" xreflabel="dummy_seclabel">
|
||||
<title>dummy_seclabel</title>
|
||||
|
||||
<indexterm zone="dummy-seclabel">
|
||||
<primary>dummy_seclabel</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
The <filename>dummy_seclabel</> module exists only to support regression
|
||||
testing of the <command>SECURITY LABEL</> statement. It is not intended
|
||||
to be used in production.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Rationale</title>
|
||||
|
||||
<para>
|
||||
The <command>SECURITY LABEL</> statement allows the user to assign security
|
||||
labels to database objects; however, security labels can only be assigned
|
||||
when specifically allowed by a loadable module, so this module is provided
|
||||
to allow proper regression testing.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Security label providers intended to be used in production will typically be
|
||||
dependent on a platform-specific feature such as
|
||||
<productname>SE-Linux</productname>. This module is platform-independent,
|
||||
and therefore better-suited to regression testing.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Usage</title>
|
||||
|
||||
<para>
|
||||
Here's a simple example of usage:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
# postgresql.conf
|
||||
shared_preload_libraries = 'dummy_seclabel'
|
||||
</programlisting>
|
||||
|
||||
<programlisting>
|
||||
postgres=# CREATE TABLE t (a int, b text);
|
||||
CREATE TABLE
|
||||
postgres=# SECURITY LABEL ON TABLE t IS 'classified';
|
||||
SECURITY LABEL
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
The <filename>dummy_seclabel</> module provides only four hardcoded
|
||||
labels: <literal>unclassified</>, <literal>classified</>,
|
||||
<literal>secret</>, and <literal>top secret</>.
|
||||
It does not allow any other strings as security labels.
|
||||
</para>
|
||||
<para>
|
||||
These labels are not used to enforce access controls. They are only used
|
||||
to check whether the <command>SECURITY LABEL</> statement works as expected,
|
||||
or not.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Author</title>
|
||||
|
||||
<para>
|
||||
KaiGai Kohei <email>kaigai@ak.jp.nec.com</email>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
@@ -207,7 +207,7 @@ SECURITY LABEL FOR selinux ON TABLE mytable IS 'system_u:object_r:sepgsql_table_
|
||||
<title>See Also</title>
|
||||
<simplelist type="inline">
|
||||
<member><xref linkend="sepgsql"></member>
|
||||
<member><xref linkend="dummy-seclabel"></member>
|
||||
<member><filename>src/test/modules/dummy_seclabel</filename></member>
|
||||
</simplelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
||||
@@ -8062,7 +8062,7 @@ SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add <link linkend="dummy-seclabel"><filename>dummy_seclabel</></link>
|
||||
Add <filename>dummy_seclabel</>
|
||||
contrib module (KaiGai Kohei)
|
||||
</para>
|
||||
|
||||
|
||||
@@ -503,7 +503,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This feature is illustrated in <xref linkend="test-shm-mq">.
|
||||
This feature is illustrated in <filename>contrib/test_shm_mq</filename>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
||||
@@ -1,90 +0,0 @@
|
||||
<!-- doc/src/sgml/test-parser.sgml -->
|
||||
|
||||
<sect1 id="test-parser" xreflabel="test_parser">
|
||||
<title>test_parser</title>
|
||||
|
||||
<indexterm zone="test-parser">
|
||||
<primary>test_parser</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<filename>test_parser</> is an example of a custom parser for full-text
|
||||
search. It doesn't do anything especially useful, but can serve as
|
||||
a starting point for developing your own parser.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<filename>test_parser</> recognizes words separated by white space,
|
||||
and returns just two token types:
|
||||
|
||||
<programlisting>
|
||||
mydb=# SELECT * FROM ts_token_type('testparser');
|
||||
tokid | alias | description
|
||||
-------+-------+---------------
|
||||
3 | word | Word
|
||||
12 | blank | Space symbols
|
||||
(2 rows)
|
||||
</programlisting>
|
||||
|
||||
These token numbers have been chosen to be compatible with the default
|
||||
parser's numbering. This allows us to use its <function>headline()</>
|
||||
function, thus keeping the example simple.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Usage</title>
|
||||
|
||||
<para>
|
||||
Installing the <literal>test_parser</> extension creates a text search
|
||||
parser <literal>testparser</>. It has no user-configurable parameters.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can test the parser with, for example,
|
||||
|
||||
<programlisting>
|
||||
mydb=# SELECT * FROM ts_parse('testparser', 'That''s my first own parser');
|
||||
tokid | token
|
||||
-------+--------
|
||||
3 | That's
|
||||
12 |
|
||||
3 | my
|
||||
12 |
|
||||
3 | first
|
||||
12 |
|
||||
3 | own
|
||||
12 |
|
||||
3 | parser
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Real-world use requires setting up a text search configuration
|
||||
that uses the parser. For example,
|
||||
|
||||
<programlisting>
|
||||
mydb=# CREATE TEXT SEARCH CONFIGURATION testcfg ( PARSER = testparser );
|
||||
CREATE TEXT SEARCH CONFIGURATION
|
||||
|
||||
mydb=# ALTER TEXT SEARCH CONFIGURATION testcfg
|
||||
mydb-# ADD MAPPING FOR word WITH english_stem;
|
||||
ALTER TEXT SEARCH CONFIGURATION
|
||||
|
||||
mydb=# SELECT to_tsvector('testcfg', 'That''s my first own parser');
|
||||
to_tsvector
|
||||
-------------------------------
|
||||
'that':1 'first':3 'parser':5
|
||||
(1 row)
|
||||
|
||||
mydb=# SELECT ts_headline('testcfg', 'Supernovae stars are the brightest phenomena in galaxies',
|
||||
mydb(# to_tsquery('testcfg', 'star'));
|
||||
ts_headline
|
||||
-----------------------------------------------------------------
|
||||
Supernovae <b>stars</b> are the brightest phenomena in galaxies
|
||||
(1 row)
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
@@ -1,71 +0,0 @@
|
||||
<!-- doc/src/sgml/test-shm-mq.sgml -->
|
||||
|
||||
<sect1 id="test-shm-mq" xreflabel="test_shm_mq">
|
||||
<title>test_shm_mq</title>
|
||||
|
||||
<indexterm zone="test-shm-mq">
|
||||
<primary>test_shm_mq</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<filename>test_shm_mq</> is an example of how to use dynamic shared memory
|
||||
and the shared memory message queue facilities to coordinate a user backend
|
||||
with the efforts of one or more background workers. It is not intended to
|
||||
do anything useful on its own; rather, it is a demonstration of how these
|
||||
facilities can be used, and a unit test of those facilities.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The function is this extension send the same message repeatedly through
|
||||
a loop of processes. The message payload, the size of the message queue
|
||||
through which it is sent, and the number of processes in the loop are
|
||||
configurable. At the end, the message may be verified to ensure that it
|
||||
has not been corrupted in transmission.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Functions</title>
|
||||
|
||||
<synopsis>
|
||||
test_shm_mq(queue_size int8, message text,
|
||||
repeat_count int4 default 1, num_workers int4 default 1)
|
||||
RETURNS void
|
||||
</synopsis>
|
||||
|
||||
<para>
|
||||
This function sends and receives messages synchronously. The user
|
||||
backend sends the provided message to the first background worker using
|
||||
a message queue of the given size. The first background worker sends
|
||||
the message to the second background worker, if the number of workers
|
||||
is greater than one, and so forth. Eventually, the last background
|
||||
worker sends the message back to the user backend. If the repeat count
|
||||
is greater than one, the user backend then sends the message back to
|
||||
the first worker. Once the message has been sent and received by all
|
||||
the coordinating processes a number of times equal to the repeat count,
|
||||
the user backend verifies that the message finally received matches the
|
||||
one originally sent and throws an error if not.
|
||||
</para>
|
||||
|
||||
<synopsis>
|
||||
test_shm_mq_pipelined(queue_size int8, message text,
|
||||
repeat_count int4 default 1, num_workers int4 default 1,
|
||||
verify bool default true)
|
||||
RETURNS void
|
||||
</synopsis>
|
||||
|
||||
<para>
|
||||
This function sends the same message multiple times, as specified by the
|
||||
repeat count, to the first background worker using a queue of the given
|
||||
size. These messages are then forwarded to each background worker in
|
||||
turn, in each case using a queue of the given size. Finally, the last
|
||||
background worker sends the messages back to the user backend. The user
|
||||
backend uses non-blocking sends and receives, so that it may begin receiving
|
||||
copies of the message before it has finished sending all copies of the
|
||||
message. The <literal>verify</> argument controls whether or not the
|
||||
received copies are checked against the message that was sent. (This
|
||||
takes nontrivial time so it may be useful to disable it for benchmarking
|
||||
purposes.)
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
Reference in New Issue
Block a user