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:
Alvaro Herrera
parent
5b12987b2e
commit
22dfd116a1
|
|
@ -16,7 +16,6 @@ SUBDIRS = \
|
|||
dblink \
|
||||
dict_int \
|
||||
dict_xsyn \
|
||||
dummy_seclabel \
|
||||
earthdistance \
|
||||
file_fdw \
|
||||
fuzzystrmatch \
|
||||
|
|
@ -51,12 +50,9 @@ SUBDIRS = \
|
|||
tablefunc \
|
||||
tcn \
|
||||
test_decoding \
|
||||
test_parser \
|
||||
test_shm_mq \
|
||||
tsearch2 \
|
||||
unaccent \
|
||||
vacuumlo \
|
||||
worker_spi
|
||||
vacuumlo
|
||||
|
||||
ifeq ($(with_openssl),yes)
|
||||
SUBDIRS += sslinfo
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
@ -12,6 +12,14 @@ subdir = src/test
|
|||
top_builddir = ../..
|
||||
include $(top_builddir)/src/Makefile.global
|
||||
|
||||
SUBDIRS = regress isolation
|
||||
SUBDIRS = regress isolation modules
|
||||
|
||||
$(recurse)
|
||||
# We want to recurse to all subdirs for all standard targets, except that
|
||||
# installcheck and install should not recurse into the subdirectory "modules".
|
||||
|
||||
recurse_alldirs_targets := $(filter-out installcheck install, $(standard_targets))
|
||||
installable_dirs := $(filter-out modules, $(SUBDIRS))
|
||||
|
||||
$(call recurse,$(recurse_alldirs_targets))
|
||||
$(call recurse,installcheck, $(installable_dirs))
|
||||
$(call recurse,install, $(installable_dirs))
|
||||
|
|
|
|||
|
|
@ -0,0 +1,13 @@
|
|||
# src/test/modules/Makefile
|
||||
|
||||
subdir = src/test/modules
|
||||
top_builddir = ../../..
|
||||
include $(top_builddir)/src/Makefile.global
|
||||
|
||||
SUBDIRS = \
|
||||
worker_spi \
|
||||
dummy_seclabel \
|
||||
test_shm_mq \
|
||||
test_parser
|
||||
|
||||
$(recurse)
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# contrib/dummy_seclabel/Makefile
|
||||
# src/test/modules/dummy_seclabel/Makefile
|
||||
|
||||
MODULES = dummy_seclabel
|
||||
PGFILEDESC = "dummy_seclabel - regression testing of the SECURITY LABEL statement"
|
||||
|
|
@ -8,8 +8,8 @@ PG_CONFIG = pg_config
|
|||
PGXS := $(shell $(PG_CONFIG) --pgxs)
|
||||
include $(PGXS)
|
||||
else
|
||||
subdir = contrib/dummy_seclabel
|
||||
top_builddir = ../..
|
||||
subdir = src/test/modules/dummy_seclabel
|
||||
top_builddir = ../../../..
|
||||
include $(top_builddir)/src/Makefile.global
|
||||
include $(top_srcdir)/contrib/contrib-global.mk
|
||||
endif
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
The dummy_seclabel module exists only to support regression
|
||||
testing of the SECURITY LABEL statement. It is not intended
|
||||
to be used in production.
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
The 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.
|
||||
|
||||
Security label providers intended to be used in production will typically be
|
||||
dependent on a platform-specific feature such as
|
||||
SE-Linux. This module is platform-independent,
|
||||
and therefore better-suited to regression testing.
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
Here's a simple example of usage:
|
||||
|
||||
# postgresql.conf
|
||||
shared_preload_libraries = 'dummy_seclabel'
|
||||
|
||||
postgres=# CREATE TABLE t (a int, b text);
|
||||
CREATE TABLE
|
||||
postgres=# SECURITY LABEL ON TABLE t IS 'classified';
|
||||
SECURITY LABEL
|
||||
|
||||
The dummy_seclabel module provides only four hardcoded
|
||||
labels: unclassified, classified,
|
||||
secret, and top secret.
|
||||
It does not allow any other strings as security labels.
|
||||
|
||||
These labels are not used to enforce access controls. They are only used
|
||||
to check whether the SECURITY LABEL statement works as expected,
|
||||
or not.
|
||||
|
||||
Author
|
||||
======
|
||||
|
||||
KaiGai Kohei <kaigai@ak.jp.nec.com>
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# contrib/test_parser/Makefile
|
||||
# src/test/modules/test_parser/Makefile
|
||||
|
||||
MODULE_big = test_parser
|
||||
OBJS = test_parser.o $(WIN32RES)
|
||||
|
|
@ -14,8 +14,8 @@ PG_CONFIG = pg_config
|
|||
PGXS := $(shell $(PG_CONFIG) --pgxs)
|
||||
include $(PGXS)
|
||||
else
|
||||
subdir = contrib/test_parser
|
||||
top_builddir = ../..
|
||||
subdir = src/test/modules/test_parser
|
||||
top_builddir = ../../../..
|
||||
include $(top_builddir)/src/Makefile.global
|
||||
include $(top_srcdir)/contrib/contrib-global.mk
|
||||
endif
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
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.
|
||||
|
||||
test_parser recognizes words separated by white space,
|
||||
and returns just two token types:
|
||||
|
||||
mydb=# SELECT * FROM ts_token_type('testparser');
|
||||
tokid | alias | description
|
||||
-------+-------+---------------
|
||||
3 | word | Word
|
||||
12 | blank | Space symbols
|
||||
(2 rows)
|
||||
|
||||
These token numbers have been chosen to be compatible with the default
|
||||
parser's numbering. This allows us to use its headline()
|
||||
function, thus keeping the example simple.
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
Installing the test_parser extension creates a text search
|
||||
parser testparser. It has no user-configurable parameters.
|
||||
|
||||
You can test the parser with, for example,
|
||||
|
||||
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
|
||||
|
||||
Real-world use requires setting up a text search configuration
|
||||
that uses the parser. For example,
|
||||
|
||||
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)
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
/* contrib/test_parser/test_parser--1.0.sql */
|
||||
/* src/test/modules/test_parser/test_parser--1.0.sql */
|
||||
|
||||
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
|
||||
\echo Use "CREATE EXTENSION test_parser" to load this file. \quit
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
/* contrib/test_parser/test_parser--unpackaged--1.0.sql */
|
||||
/* src/test/modules/test_parser/test_parser--unpackaged--1.0.sql */
|
||||
|
||||
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
|
||||
\echo Use "CREATE EXTENSION test_parser FROM unpackaged" to load this file. \quit
|
||||
|
|
@ -6,7 +6,7 @@
|
|||
* Copyright (c) 2007-2014, PostgreSQL Global Development Group
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* contrib/test_parser/test_parser.c
|
||||
* src/test/modules/test_parser/test_parser.c
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# contrib/test_shm_mq/Makefile
|
||||
# src/test/modules/test_shm_mq/Makefile
|
||||
|
||||
MODULE_big = test_shm_mq
|
||||
OBJS = test.o setup.o worker.o $(WIN32RES)
|
||||
|
|
@ -14,8 +14,8 @@ PG_CONFIG = pg_config
|
|||
PGXS := $(shell $(PG_CONFIG) --pgxs)
|
||||
include $(PGXS)
|
||||
else
|
||||
subdir = contrib/test_shm_mq
|
||||
top_builddir = ../..
|
||||
subdir = src/test/modules/test_shm_mq
|
||||
top_builddir = ../../../..
|
||||
include $(top_builddir)/src/Makefile.global
|
||||
include $(top_srcdir)/contrib/contrib-global.mk
|
||||
endif
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
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.
|
||||
|
||||
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.
|
||||
|
||||
Functions
|
||||
=========
|
||||
|
||||
|
||||
test_shm_mq(queue_size int8, message text,
|
||||
repeat_count int4 default 1, num_workers int4 default 1)
|
||||
RETURNS void
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
|
||||
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 '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.)
|
||||
|
|
@ -5,10 +5,10 @@
|
|||
* number of background workers for shared memory message queue
|
||||
* testing.
|
||||
*
|
||||
* Copyright (C) 2013, PostgreSQL Global Development Group
|
||||
* Copyright (C) 2013-2014, PostgreSQL Global Development Group
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* contrib/test_shm_mq/setup.c
|
||||
* src/test/modules/test_shm_mq/setup.c
|
||||
*
|
||||
* -------------------------------------------------------------------------
|
||||
*/
|
||||
|
|
@ -3,10 +3,10 @@
|
|||
* test.c
|
||||
* Test harness code for shared memory message queues.
|
||||
*
|
||||
* Copyright (C) 2013, PostgreSQL Global Development Group
|
||||
* Copyright (C) 2013-2014, PostgreSQL Global Development Group
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* contrib/test_shm_mq/test.c
|
||||
* src/test/modules/test_shm_mq/test.c
|
||||
*
|
||||
* -------------------------------------------------------------------------
|
||||
*/
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
/* contrib/test_shm_mq/test_shm_mq--1.0.sql */
|
||||
/* src/test/modules/test_shm_mq/test_shm_mq--1.0.sql */
|
||||
|
||||
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
|
||||
\echo Use "CREATE EXTENSION test_shm_mq" to load this file. \quit
|
||||
|
|
@ -6,7 +6,7 @@
|
|||
* Copyright (C) 2013, PostgreSQL Global Development Group
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* contrib/test_shm_mq/test_shm_mq.h
|
||||
* src/test/modules/test_shm_mq/test_shm_mq.h
|
||||
*
|
||||
* -------------------------------------------------------------------------
|
||||
*/
|
||||
|
|
@ -9,10 +9,10 @@
|
|||
* but it should be possible to use much of the control logic just
|
||||
* as presented here.
|
||||
*
|
||||
* Copyright (C) 2013, PostgreSQL Global Development Group
|
||||
* Copyright (C) 2013-2014, PostgreSQL Global Development Group
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* contrib/test_shm_mq/worker.c
|
||||
* src/test/modules/test_shm_mq/worker.c
|
||||
*
|
||||
* -------------------------------------------------------------------------
|
||||
*/
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# contrib/worker_spi/Makefile
|
||||
# src/test/modules/worker_spi/Makefile
|
||||
|
||||
MODULES = worker_spi
|
||||
|
||||
|
|
@ -11,8 +11,8 @@ PG_CONFIG = pg_config
|
|||
PGXS := $(shell $(PG_CONFIG) --pgxs)
|
||||
include $(PGXS)
|
||||
else
|
||||
subdir = contrib/worker_spi
|
||||
top_builddir = ../..
|
||||
subdir = src/test/modules/worker_spi
|
||||
top_builddir = ../../../..
|
||||
include $(top_builddir)/src/Makefile.global
|
||||
include $(top_srcdir)/contrib/contrib-global.mk
|
||||
endif
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
/* contrib/worker_spi/worker_spi--1.0.sql */
|
||||
/* src/test/modules/worker_spi/worker_spi--1.0.sql */
|
||||
|
||||
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
|
||||
\echo Use "CREATE EXTENSION worker_spi" to load this file. \quit
|
||||
|
|
@ -13,10 +13,10 @@
|
|||
* "delta" type. Delta rows will be deleted by this worker and their values
|
||||
* aggregated into the total.
|
||||
*
|
||||
* Copyright (C) 2013, PostgreSQL Global Development Group
|
||||
* Copyright (C) 2013-2014, PostgreSQL Global Development Group
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* contrib/worker_spi/worker_spi.c
|
||||
* src/test/modules/worker_spi/worker_spi.c
|
||||
*
|
||||
* -------------------------------------------------------------------------
|
||||
*/
|
||||
|
|
@ -101,7 +101,7 @@ installdirs-tests: installdirs
|
|||
$(MKDIR_P) $(patsubst $(srcdir)/%/,'$(DESTDIR)$(pkglibdir)/regress/%',$(sort $(dir $(regress_data_files))))
|
||||
|
||||
|
||||
# Get some extra C modules from contrib/spi and contrib/dummy_seclabel...
|
||||
# Get some extra C modules from contrib/spi and src/test/modules/dummy_seclabel...
|
||||
|
||||
all: refint$(DLSUFFIX) autoinc$(DLSUFFIX) dummy_seclabel$(DLSUFFIX)
|
||||
|
||||
|
|
@ -111,22 +111,22 @@ refint$(DLSUFFIX): $(top_builddir)/contrib/spi/refint$(DLSUFFIX)
|
|||
autoinc$(DLSUFFIX): $(top_builddir)/contrib/spi/autoinc$(DLSUFFIX)
|
||||
cp $< $@
|
||||
|
||||
dummy_seclabel$(DLSUFFIX): $(top_builddir)/contrib/dummy_seclabel/dummy_seclabel$(DLSUFFIX)
|
||||
dummy_seclabel$(DLSUFFIX): $(top_builddir)/src/test/modules/dummy_seclabel/dummy_seclabel$(DLSUFFIX)
|
||||
cp $< $@
|
||||
|
||||
$(top_builddir)/contrib/spi/refint$(DLSUFFIX): | submake-contrib-spi ;
|
||||
|
||||
$(top_builddir)/contrib/spi/autoinc$(DLSUFFIX): | submake-contrib-spi ;
|
||||
|
||||
$(top_builddir)/contrib/dummy_seclabel/dummy_seclabel$(DLSUFFIX): | submake-contrib-dummy_seclabel ;
|
||||
$(top_builddir)/src/test/modules/dummy_seclabel/dummy_seclabel$(DLSUFFIX): | submake-dummy_seclabel ;
|
||||
|
||||
submake-contrib-spi:
|
||||
$(MAKE) -C $(top_builddir)/contrib/spi
|
||||
|
||||
submake-contrib-dummy_seclabel:
|
||||
$(MAKE) -C $(top_builddir)/contrib/dummy_seclabel
|
||||
submake-dummy_seclabel:
|
||||
$(MAKE) -C $(top_builddir)/src/test/modules/dummy_seclabel
|
||||
|
||||
.PHONY: submake-contrib-spi submake-contrib-dummy_seclabel
|
||||
.PHONY: submake-contrib-spi submake-dummy_seclabel
|
||||
|
||||
# Tablespace setup
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue