diff options
| author | Tom Lane | 2018-04-09 18:39:58 +0000 |
|---|---|---|
| committer | Tom Lane | 2018-04-09 18:39:58 +0000 |
| commit | af1a949109d8212711df943c053b1038c0afdae1 (patch) | |
| tree | 3d532e1bcd3ce3dfd1fa7dbb41480e25d342981e /src/include/common | |
| parent | f5543d47bcb2fee2ab69220f51e2078c11e19843 (diff) | |
Further cleanup of client dependencies on src/include/catalog headers.
In commit 9c0a0de4c, I'd failed to notice that catalog/catalog.h
should also be considered a frontend-unsafe header, because it includes
(and needs) the full form of pg_class.h, not to mention relcache.h.
However, various frontend code was depending on it to get
TABLESPACE_VERSION_DIRECTORY, so refactoring of some sort is called for.
The cleanest answer seems to be to move TABLESPACE_VERSION_DIRECTORY,
as well as the OIDCHARS symbol, to common/relpath.h. Do that, and mop up
inclusions as necessary. (I found that quite a few current users of
catalog/catalog.h don't seem to need it at all anymore, apparently as a
result of the refactorings that created common/relpath.[hc]. And
initdb.c needed it only as a route to pg_class_d.h.)
Discussion: https://postgr.es/m/6629.1523294509@sss.pgh.pa.us
Diffstat (limited to 'src/include/common')
| -rw-r--r-- | src/include/common/relpath.h | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/src/include/common/relpath.h b/src/include/common/relpath.h index 9137dc9ed39..82d817a53c7 100644 --- a/src/include/common/relpath.h +++ b/src/include/common/relpath.h @@ -14,6 +14,22 @@ #define RELPATH_H /* + * 'pgrminclude ignore' needed here because CppAsString2() does not throw + * an error if the symbol is not defined. + */ +#include "catalog/catversion.h" /* pgrminclude ignore */ + + +/* + * Name of major-version-specific tablespace subdirectories + */ +#define TABLESPACE_VERSION_DIRECTORY "PG_" PG_MAJORVERSION "_" \ + CppAsString2(CATALOG_VERSION_NO) + +/* Characters to allow for an OID in a relation path */ +#define OIDCHARS 10 /* max chars printed by %u */ + +/* * Stuff for fork names. * * The physical storage of a relation consists of one or more forks. |
