Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* extensible.c
|
|
|
|
* Support for extensible node types
|
|
|
|
*
|
|
|
|
* Loadable modules can define what are in effect new types of nodes using
|
|
|
|
* the routines in this file. All such nodes are flagged T_ExtensibleNode,
|
|
|
|
* with the extnodename field distinguishing the specific type. Use
|
|
|
|
* RegisterExtensibleNodeMethods to register a new type of extensible node,
|
|
|
|
* and GetExtensibleNodeMethods to get information about a previously
|
|
|
|
* registered type of extensible node.
|
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/backend/nodes/extensible.c
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "nodes/extensible.h"
|
|
|
|
#include "utils/hsearch.h"
|
|
|
|
|
|
|
|
static HTAB *extensible_node_methods = NULL;
|
2016-03-29 17:00:18 +02:00
|
|
|
static HTAB *custom_scan_methods = NULL;
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
char extnodename[EXTNODENAME_MAX_LEN];
|
2016-03-29 17:00:18 +02:00
|
|
|
const void *extnodemethods;
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
} ExtensibleNodeEntry;
|
|
|
|
|
|
|
|
/*
|
2016-04-11 20:44:51 +02:00
|
|
|
* An internal function to register a new callback structure
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
*/
|
2016-03-29 17:00:18 +02:00
|
|
|
static void
|
|
|
|
RegisterExtensibleNodeEntry(HTAB **p_htable, const char *htable_label,
|
|
|
|
const char *extnodename,
|
|
|
|
const void *extnodemethods)
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
{
|
|
|
|
ExtensibleNodeEntry *entry;
|
|
|
|
bool found;
|
|
|
|
|
2016-03-29 17:00:18 +02:00
|
|
|
if (*p_htable == NULL)
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
{
|
|
|
|
HASHCTL ctl;
|
|
|
|
|
|
|
|
memset(&ctl, 0, sizeof(HASHCTL));
|
2016-03-01 19:17:09 +01:00
|
|
|
ctl.keysize = EXTNODENAME_MAX_LEN;
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
ctl.entrysize = sizeof(ExtensibleNodeEntry);
|
2016-03-29 17:00:18 +02:00
|
|
|
|
|
|
|
*p_htable = hash_create(htable_label, 100, &ctl, HASH_ELEM);
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
}
|
|
|
|
|
2016-03-29 17:00:18 +02:00
|
|
|
if (strlen(extnodename) >= EXTNODENAME_MAX_LEN)
|
2016-03-14 18:48:35 +01:00
|
|
|
elog(ERROR, "extensible node name is too long");
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
|
2016-03-29 17:00:18 +02:00
|
|
|
entry = (ExtensibleNodeEntry *) hash_search(*p_htable,
|
|
|
|
extnodename,
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
HASH_ENTER, &found);
|
|
|
|
if (found)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DUPLICATE_OBJECT),
|
|
|
|
errmsg("extensible node type \"%s\" already exists",
|
2016-03-29 17:00:18 +02:00
|
|
|
extnodename)));
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
|
2016-03-29 17:00:18 +02:00
|
|
|
entry->extnodemethods = extnodemethods;
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2016-03-29 17:00:18 +02:00
|
|
|
* Register a new type of extensible node.
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
*/
|
2016-03-29 17:00:18 +02:00
|
|
|
void
|
|
|
|
RegisterExtensibleNodeMethods(const ExtensibleNodeMethods *methods)
|
|
|
|
{
|
|
|
|
RegisterExtensibleNodeEntry(&extensible_node_methods,
|
|
|
|
"Extensible Node Methods",
|
|
|
|
methods->extnodename,
|
|
|
|
methods);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Register a new type of custom scan node
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
RegisterCustomScanMethods(const CustomScanMethods *methods)
|
|
|
|
{
|
|
|
|
RegisterExtensibleNodeEntry(&custom_scan_methods,
|
|
|
|
"Custom Scan Methods",
|
|
|
|
methods->CustomName,
|
|
|
|
methods);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* An internal routine to get an ExtensibleNodeEntry by the given identifier
|
|
|
|
*/
|
|
|
|
static const void *
|
|
|
|
GetExtensibleNodeEntry(HTAB *htable, const char *extnodename, bool missing_ok)
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
{
|
|
|
|
ExtensibleNodeEntry *entry = NULL;
|
|
|
|
|
2016-03-29 17:00:18 +02:00
|
|
|
if (htable != NULL)
|
|
|
|
entry = (ExtensibleNodeEntry *) hash_search(htable,
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
extnodename,
|
|
|
|
HASH_FIND, NULL);
|
|
|
|
if (!entry)
|
|
|
|
{
|
|
|
|
if (missing_ok)
|
|
|
|
return NULL;
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("ExtensibleNodeMethods \"%s\" was not registered",
|
|
|
|
extnodename)));
|
|
|
|
}
|
|
|
|
|
2016-03-29 17:00:18 +02:00
|
|
|
return entry->extnodemethods;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the methods for a given type of extensible node.
|
|
|
|
*/
|
|
|
|
const ExtensibleNodeMethods *
|
|
|
|
GetExtensibleNodeMethods(const char *extnodename, bool missing_ok)
|
|
|
|
{
|
|
|
|
return (const ExtensibleNodeMethods *)
|
|
|
|
GetExtensibleNodeEntry(extensible_node_methods,
|
|
|
|
extnodename,
|
|
|
|
missing_ok);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the methods for a given name of CustomScanMethods
|
|
|
|
*/
|
|
|
|
const CustomScanMethods *
|
|
|
|
GetCustomScanMethods(const char *CustomName, bool missing_ok)
|
|
|
|
{
|
|
|
|
return (const CustomScanMethods *)
|
|
|
|
GetExtensibleNodeEntry(custom_scan_methods,
|
|
|
|
CustomName,
|
|
|
|
missing_ok);
|
Introduce extensible node types.
An extensible node is always tagged T_Extensible, but the extnodename
field identifies it more specifically; it may also include arbitrary
private data. Extensible nodes can be copied, tested for equality,
serialized, and deserialized, but the core system doesn't know
anything about them otherwise. Some extensions may find it useful to
include these nodes in fdw_private or custom_private lists in lieu of
arm-wrestling their data into a format that the core code can
understand.
Along the way, so as not to burden the authors of such extensible
node types too much, expose the functions for writing serialized
tokens, and for serializing and deserializing bitmapsets.
KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund
and by me, and further edited by me.
2016-02-12 15:31:16 +01:00
|
|
|
}
|