2021-01-13 09:33:33 +01:00
|
|
|
/*
|
|
|
|
* gistfuncs.c
|
|
|
|
* Functions to investigate the content of GiST indexes
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Copyright (c) 2014-2022, PostgreSQL Global Development Group
|
2021-01-13 09:33:33 +01:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* contrib/pageinspect/gistfuncs.c
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "access/gist.h"
|
|
|
|
#include "access/gist_private.h"
|
|
|
|
#include "access/htup.h"
|
|
|
|
#include "access/relation.h"
|
|
|
|
#include "catalog/namespace.h"
|
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a sub-range, but what we are looking for is an exact
match on BLCKSZ. After considering a few options here, I have settled
down to do a generalization of get_page_from_raw(). Most of the SQL
functions already used that, and this is not strictly required if not
accessing an 8-byte-wide value from a raw page, but this feels safer in
the long run for alignment-picky environment, particularly if a code
path begins to access such values. This also reduces the number of
strings that need to be translated.
- The BRIN function brin_page_items() uses a Relation but it did not
check the access method of the opened index, potentially leading to
crashes. All the other functions in need of a Relation already did
that.
- Some code paths could fail on elog(), but we should to use ereport()
for failures that can be triggered by the user.
Tests are added to stress all the cases that are fixed as of this
commit, with some junk raw pages (\set VERBOSITY ensures that this works
across all page sizes) and unexpected index types when functions open
relations.
Author: Michael Paquier, Justin Prysby
Discussion: https://postgr.es/m/20220218030020.GA1137@telsasoft.com
Backpatch-through: 10
2022-03-16 03:19:39 +01:00
|
|
|
#include "catalog/pg_am_d.h"
|
2021-01-13 09:33:33 +01:00
|
|
|
#include "funcapi.h"
|
|
|
|
#include "miscadmin.h"
|
|
|
|
#include "pageinspect.h"
|
|
|
|
#include "storage/itemptr.h"
|
|
|
|
#include "utils/array.h"
|
|
|
|
#include "utils/builtins.h"
|
|
|
|
#include "utils/pg_lsn.h"
|
pageinspect: Fix gist_page_items() with included columns
Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes. This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.
This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with. In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.
ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.
While on it, this commit fixes a third problem related to the amount of
data reported for key attributes. The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available. This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect. Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().
The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14
2023-05-19 05:38:15 +02:00
|
|
|
#include "utils/lsyscache.h"
|
|
|
|
#include "utils/rel.h"
|
|
|
|
#include "utils/ruleutils.h"
|
2021-01-13 09:33:33 +01:00
|
|
|
#include "utils/varlena.h"
|
|
|
|
|
|
|
|
PG_FUNCTION_INFO_V1(gist_page_opaque_info);
|
|
|
|
PG_FUNCTION_INFO_V1(gist_page_items);
|
|
|
|
PG_FUNCTION_INFO_V1(gist_page_items_bytea);
|
|
|
|
|
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a sub-range, but what we are looking for is an exact
match on BLCKSZ. After considering a few options here, I have settled
down to do a generalization of get_page_from_raw(). Most of the SQL
functions already used that, and this is not strictly required if not
accessing an 8-byte-wide value from a raw page, but this feels safer in
the long run for alignment-picky environment, particularly if a code
path begins to access such values. This also reduces the number of
strings that need to be translated.
- The BRIN function brin_page_items() uses a Relation but it did not
check the access method of the opened index, potentially leading to
crashes. All the other functions in need of a Relation already did
that.
- Some code paths could fail on elog(), but we should to use ereport()
for failures that can be triggered by the user.
Tests are added to stress all the cases that are fixed as of this
commit, with some junk raw pages (\set VERBOSITY ensures that this works
across all page sizes) and unexpected index types when functions open
relations.
Author: Michael Paquier, Justin Prysby
Discussion: https://postgr.es/m/20220218030020.GA1137@telsasoft.com
Backpatch-through: 10
2022-03-16 03:19:39 +01:00
|
|
|
#define IS_GIST(r) ((r)->rd_rel->relam == GIST_AM_OID)
|
|
|
|
|
2021-01-13 09:33:33 +01:00
|
|
|
#define ItemPointerGetDatum(X) PointerGetDatum(X)
|
|
|
|
|
|
|
|
|
2023-03-02 06:03:08 +01:00
|
|
|
static Page verify_gist_page(bytea *raw_page);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Verify that the given bytea contains a GIST page or die in the attempt.
|
|
|
|
* A pointer to the page is returned.
|
|
|
|
*/
|
|
|
|
static Page
|
|
|
|
verify_gist_page(bytea *raw_page)
|
2021-01-13 09:33:33 +01:00
|
|
|
{
|
2023-03-02 06:03:08 +01:00
|
|
|
Page page = get_page_from_raw(raw_page);
|
2021-01-13 09:33:33 +01:00
|
|
|
GISTPageOpaque opaq;
|
|
|
|
|
pageinspect: Fix handling of all-zero pages
Getting from get_raw_page() an all-zero page is considered as a valid
case by the buffer manager and it can happen for example when finding a
corrupted page with zero_damaged_pages enabled (using zero_damaged_pages
to look at corrupted pages happens), or after a crash when a relation
file is extended before any WAL for its new data is generated (before a
vacuum or autovacuum job comes in to do some cleanup).
However, all the functions of pageinspect, as of the index AMs (except
hash that has its own idea of new pages), heap, the FSM or the page
header have never worked with all-zero pages, causing various crashes
when going through the page internals.
This commit changes all the pageinspect functions to be compliant with
all-zero pages, where the choice is made to return NULL or no rows for
SRFs when finding a new page. get_raw_page() still works the same way,
returning a batch of zeros in the bytea of the page retrieved. A hard
error could be used but NULL, while more invasive, is useful when
scanning relation files in full to get a batch of results for a single
relation in one query. Tests are added for all the code paths
impacted.
Reported-by: Daria Lepikhova
Author: Michael Paquier
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-04-14 08:08:03 +02:00
|
|
|
if (PageIsNew(page))
|
2023-03-02 06:03:08 +01:00
|
|
|
return page;
|
pageinspect: Fix handling of all-zero pages
Getting from get_raw_page() an all-zero page is considered as a valid
case by the buffer manager and it can happen for example when finding a
corrupted page with zero_damaged_pages enabled (using zero_damaged_pages
to look at corrupted pages happens), or after a crash when a relation
file is extended before any WAL for its new data is generated (before a
vacuum or autovacuum job comes in to do some cleanup).
However, all the functions of pageinspect, as of the index AMs (except
hash that has its own idea of new pages), heap, the FSM or the page
header have never worked with all-zero pages, causing various crashes
when going through the page internals.
This commit changes all the pageinspect functions to be compliant with
all-zero pages, where the choice is made to return NULL or no rows for
SRFs when finding a new page. get_raw_page() still works the same way,
returning a batch of zeros in the bytea of the page retrieved. A hard
error could be used but NULL, while more invasive, is useful when
scanning relation files in full to get a batch of results for a single
relation in one query. Tests are added for all the code paths
impacted.
Reported-by: Daria Lepikhova
Author: Michael Paquier
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-04-14 08:08:03 +02:00
|
|
|
|
pageinspect: Add more sanity checks to prevent out-of-bound reads
A couple of code paths use the special area on the page passed by the
function caller, expecting to find some data in it. However, feeding
an incorrect page can lead to out-of-bound reads when trying to access
the page special area (like a heap page that has no special area,
leading PageGetSpecialPointer() to grab a pointer outside the allocated
page).
The functions used for hash and btree indexes have some protection
already against that, while some other functions using a relation OID
as argument would make sure that the access method involved is correct,
but functions taking in input a raw page without knowing the relation
the page is attached to would run into problems.
This commit improves the set of checks used in the code paths of BRIN,
btree (including one check if a leaf page is found with a non-zero
level), GIN and GiST to verify that the page given in input has a
special area size that fits with each access method, which is done
though PageGetSpecialSize(), becore calling PageGetSpecialPointer().
The scope of the checks done is limited to work with pages that one
would pass after getting a block with get_raw_page(), as it is possible
to craft byteas that could bypass existing code paths. Having too many
checks would also impact the usability of pageinspect, as the existing
code is very useful to look at the content details in a corrupted page,
so the focus is really to avoid out-of-bound reads as this is never a
good thing even with functions whose execution is limited to
superusers.
The safest approach could be to rework the functions so as these fetch a
block using a relation OID and a block number, but there are also cases
where using a raw page is useful.
Tests are added to cover all the code paths that needed such checks, and
an error message for hash indexes is reworded to fit better with what
this commit adds.
Reported-By: Alexander Lakhin
Author: Julien Rouhaud, Michael Paquier
Discussion: https://postgr.es/m/16527-ef7606186f0610a1@postgresql.org
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-03-27 10:53:40 +02:00
|
|
|
/* verify the special space has the expected size */
|
|
|
|
if (PageGetSpecialSize(page) != MAXALIGN(sizeof(GISTPageOpaqueData)))
|
2022-05-12 21:17:30 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("input page is not a valid %s page", "GiST"),
|
|
|
|
errdetail("Expected special size %d, got %d.",
|
|
|
|
(int) MAXALIGN(sizeof(GISTPageOpaqueData)),
|
|
|
|
(int) PageGetSpecialSize(page))));
|
pageinspect: Add more sanity checks to prevent out-of-bound reads
A couple of code paths use the special area on the page passed by the
function caller, expecting to find some data in it. However, feeding
an incorrect page can lead to out-of-bound reads when trying to access
the page special area (like a heap page that has no special area,
leading PageGetSpecialPointer() to grab a pointer outside the allocated
page).
The functions used for hash and btree indexes have some protection
already against that, while some other functions using a relation OID
as argument would make sure that the access method involved is correct,
but functions taking in input a raw page without knowing the relation
the page is attached to would run into problems.
This commit improves the set of checks used in the code paths of BRIN,
btree (including one check if a leaf page is found with a non-zero
level), GIN and GiST to verify that the page given in input has a
special area size that fits with each access method, which is done
though PageGetSpecialSize(), becore calling PageGetSpecialPointer().
The scope of the checks done is limited to work with pages that one
would pass after getting a block with get_raw_page(), as it is possible
to craft byteas that could bypass existing code paths. Having too many
checks would also impact the usability of pageinspect, as the existing
code is very useful to look at the content details in a corrupted page,
so the focus is really to avoid out-of-bound reads as this is never a
good thing even with functions whose execution is limited to
superusers.
The safest approach could be to rework the functions so as these fetch a
block using a relation OID and a block number, but there are also cases
where using a raw page is useful.
Tests are added to cover all the code paths that needed such checks, and
an error message for hash indexes is reworded to fit better with what
this commit adds.
Reported-By: Alexander Lakhin
Author: Julien Rouhaud, Michael Paquier
Discussion: https://postgr.es/m/16527-ef7606186f0610a1@postgresql.org
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-03-27 10:53:40 +02:00
|
|
|
|
2022-04-02 04:27:20 +02:00
|
|
|
opaq = GistPageGetOpaque(page);
|
pageinspect: Add more sanity checks to prevent out-of-bound reads
A couple of code paths use the special area on the page passed by the
function caller, expecting to find some data in it. However, feeding
an incorrect page can lead to out-of-bound reads when trying to access
the page special area (like a heap page that has no special area,
leading PageGetSpecialPointer() to grab a pointer outside the allocated
page).
The functions used for hash and btree indexes have some protection
already against that, while some other functions using a relation OID
as argument would make sure that the access method involved is correct,
but functions taking in input a raw page without knowing the relation
the page is attached to would run into problems.
This commit improves the set of checks used in the code paths of BRIN,
btree (including one check if a leaf page is found with a non-zero
level), GIN and GiST to verify that the page given in input has a
special area size that fits with each access method, which is done
though PageGetSpecialSize(), becore calling PageGetSpecialPointer().
The scope of the checks done is limited to work with pages that one
would pass after getting a block with get_raw_page(), as it is possible
to craft byteas that could bypass existing code paths. Having too many
checks would also impact the usability of pageinspect, as the existing
code is very useful to look at the content details in a corrupted page,
so the focus is really to avoid out-of-bound reads as this is never a
good thing even with functions whose execution is limited to
superusers.
The safest approach could be to rework the functions so as these fetch a
block using a relation OID and a block number, but there are also cases
where using a raw page is useful.
Tests are added to cover all the code paths that needed such checks, and
an error message for hash indexes is reworded to fit better with what
this commit adds.
Reported-By: Alexander Lakhin
Author: Julien Rouhaud, Michael Paquier
Discussion: https://postgr.es/m/16527-ef7606186f0610a1@postgresql.org
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-03-27 10:53:40 +02:00
|
|
|
if (opaq->gist_page_id != GIST_PAGE_ID)
|
2022-05-12 21:17:30 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("input page is not a valid %s page", "GiST"),
|
|
|
|
errdetail("Expected %08x, got %08x.",
|
|
|
|
GIST_PAGE_ID,
|
|
|
|
opaq->gist_page_id)));
|
2021-01-13 09:33:33 +01:00
|
|
|
|
2023-03-02 06:03:08 +01:00
|
|
|
return page;
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
gist_page_opaque_info(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
bytea *raw_page = PG_GETARG_BYTEA_P(0);
|
|
|
|
TupleDesc tupdesc;
|
|
|
|
Page page;
|
|
|
|
HeapTuple resultTuple;
|
|
|
|
Datum values[4];
|
|
|
|
bool nulls[4];
|
|
|
|
Datum flags[16];
|
|
|
|
int nflags = 0;
|
|
|
|
uint16 flagbits;
|
|
|
|
|
|
|
|
if (!superuser())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("must be superuser to use raw page functions")));
|
|
|
|
|
|
|
|
page = verify_gist_page(raw_page);
|
|
|
|
|
|
|
|
if (PageIsNew(page))
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
2021-01-13 09:33:33 +01:00
|
|
|
/* Build a tuple descriptor for our result type */
|
|
|
|
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
|
|
|
|
elog(ERROR, "return type must be a row type");
|
|
|
|
|
|
|
|
/* Convert the flags bitmask to an array of human-readable names */
|
2023-03-02 06:03:08 +01:00
|
|
|
flagbits = GistPageGetOpaque(page)->flags;
|
2021-01-13 09:33:33 +01:00
|
|
|
if (flagbits & F_LEAF)
|
|
|
|
flags[nflags++] = CStringGetTextDatum("leaf");
|
|
|
|
if (flagbits & F_DELETED)
|
|
|
|
flags[nflags++] = CStringGetTextDatum("deleted");
|
|
|
|
if (flagbits & F_TUPLES_DELETED)
|
|
|
|
flags[nflags++] = CStringGetTextDatum("tuples_deleted");
|
|
|
|
if (flagbits & F_FOLLOW_RIGHT)
|
|
|
|
flags[nflags++] = CStringGetTextDatum("follow_right");
|
|
|
|
if (flagbits & F_HAS_GARBAGE)
|
|
|
|
flags[nflags++] = CStringGetTextDatum("has_garbage");
|
|
|
|
flagbits &= ~(F_LEAF | F_DELETED | F_TUPLES_DELETED | F_FOLLOW_RIGHT | F_HAS_GARBAGE);
|
|
|
|
if (flagbits)
|
|
|
|
{
|
|
|
|
/* any flags we don't recognize are printed in hex */
|
|
|
|
flags[nflags++] = DirectFunctionCall1(to_hex32, Int32GetDatum(flagbits));
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(nulls, 0, sizeof(nulls));
|
|
|
|
|
|
|
|
values[0] = LSNGetDatum(PageGetLSN(page));
|
|
|
|
values[1] = LSNGetDatum(GistPageGetNSN(page));
|
2023-03-02 06:03:08 +01:00
|
|
|
values[2] = Int64GetDatum(GistPageGetOpaque(page)->rightlink);
|
2021-01-13 09:33:33 +01:00
|
|
|
values[3] = PointerGetDatum(construct_array(flags, nflags,
|
|
|
|
TEXTOID,
|
|
|
|
-1, false, TYPALIGN_INT));
|
|
|
|
|
|
|
|
/* Build and return the result tuple. */
|
|
|
|
resultTuple = heap_form_tuple(tupdesc, values, nulls);
|
|
|
|
|
|
|
|
return HeapTupleGetDatum(resultTuple);
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
gist_page_items_bytea(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
bytea *raw_page = PG_GETARG_BYTEA_P(0);
|
2021-01-17 23:46:03 +01:00
|
|
|
ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
|
|
|
|
Page page;
|
|
|
|
OffsetNumber offset;
|
2021-02-15 04:43:25 +01:00
|
|
|
OffsetNumber maxoff = InvalidOffsetNumber;
|
2021-01-13 09:33:33 +01:00
|
|
|
|
|
|
|
if (!superuser())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("must be superuser to use raw page functions")));
|
|
|
|
|
2022-10-18 03:22:40 +02:00
|
|
|
InitMaterializedSRF(fcinfo, 0);
|
2021-01-13 09:33:33 +01:00
|
|
|
|
2023-03-02 06:03:08 +01:00
|
|
|
page = verify_gist_page(raw_page);
|
2021-01-13 09:33:33 +01:00
|
|
|
|
pageinspect: Fix handling of all-zero pages
Getting from get_raw_page() an all-zero page is considered as a valid
case by the buffer manager and it can happen for example when finding a
corrupted page with zero_damaged_pages enabled (using zero_damaged_pages
to look at corrupted pages happens), or after a crash when a relation
file is extended before any WAL for its new data is generated (before a
vacuum or autovacuum job comes in to do some cleanup).
However, all the functions of pageinspect, as of the index AMs (except
hash that has its own idea of new pages), heap, the FSM or the page
header have never worked with all-zero pages, causing various crashes
when going through the page internals.
This commit changes all the pageinspect functions to be compliant with
all-zero pages, where the choice is made to return NULL or no rows for
SRFs when finding a new page. get_raw_page() still works the same way,
returning a batch of zeros in the bytea of the page retrieved. A hard
error could be used but NULL, while more invasive, is useful when
scanning relation files in full to get a batch of results for a single
relation in one query. Tests are added for all the code paths
impacted.
Reported-by: Daria Lepikhova
Author: Michael Paquier
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-04-14 08:08:03 +02:00
|
|
|
if (PageIsNew(page))
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
2021-02-15 04:43:25 +01:00
|
|
|
/* Avoid bogus PageGetMaxOffsetNumber() call with deleted pages */
|
2021-01-17 23:46:03 +01:00
|
|
|
if (GistPageIsDeleted(page))
|
|
|
|
elog(NOTICE, "page is deleted");
|
2021-02-15 04:43:25 +01:00
|
|
|
else
|
|
|
|
maxoff = PageGetMaxOffsetNumber(page);
|
2021-01-13 09:33:33 +01:00
|
|
|
|
2021-01-17 23:46:03 +01:00
|
|
|
for (offset = FirstOffsetNumber;
|
2021-02-15 04:43:25 +01:00
|
|
|
offset <= maxoff;
|
2021-01-17 23:46:03 +01:00
|
|
|
offset++)
|
2021-01-13 09:33:33 +01:00
|
|
|
{
|
2021-02-15 05:11:11 +01:00
|
|
|
Datum values[5];
|
|
|
|
bool nulls[5];
|
2021-01-13 09:33:33 +01:00
|
|
|
ItemId id;
|
|
|
|
IndexTuple itup;
|
|
|
|
bytea *tuple_bytea;
|
|
|
|
int tuple_len;
|
|
|
|
|
|
|
|
id = PageGetItemId(page, offset);
|
|
|
|
|
|
|
|
if (!ItemIdIsValid(id))
|
|
|
|
elog(ERROR, "invalid ItemId");
|
|
|
|
|
|
|
|
itup = (IndexTuple) PageGetItem(page, id);
|
|
|
|
tuple_len = IndexTupleSize(itup);
|
|
|
|
|
|
|
|
memset(nulls, 0, sizeof(nulls));
|
|
|
|
|
|
|
|
values[0] = DatumGetInt16(offset);
|
|
|
|
values[1] = ItemPointerGetDatum(&itup->t_tid);
|
|
|
|
values[2] = Int32GetDatum((int) IndexTupleSize(itup));
|
|
|
|
|
|
|
|
tuple_bytea = (bytea *) palloc(tuple_len + VARHDRSZ);
|
|
|
|
SET_VARSIZE(tuple_bytea, tuple_len + VARHDRSZ);
|
|
|
|
memcpy(VARDATA(tuple_bytea), itup, tuple_len);
|
2021-02-15 05:11:11 +01:00
|
|
|
values[3] = BoolGetDatum(ItemIdIsDead(id));
|
|
|
|
values[4] = PointerGetDatum(tuple_bytea);
|
2021-01-13 09:33:33 +01:00
|
|
|
|
Simplify SRFs using materialize mode in contrib/ modules
9e98583 introduced a helper to centralize building their needed state
(tuplestore, tuple descriptors, etc.), checking for any errors. This
commit updates all places of contrib/ that can be switched to use
SetSingleFuncCall() as a drop-in replacement, resulting in the removal
of a lot of boilerplate code in all the modules updated by this commit.
Per analysis, some places remain as they are:
- pg_logdir_ls() in adminpack/ uses historically TYPEFUNC_RECORD as
return type, and I suspect that changing it may cause issues at run-time
with some of its past versions, down to 1.0.
- dblink/ uses a wrapper function doing exactly the work of
SetSingleFuncCall(). Here the switch should be possible, but rather
invasive so it does not seem the extra backpatch maintenance cost.
- tablefunc/, similarly, uses multiple helper functions with portions of
SetSingleFuncCall() spread across the code paths of this module.
Author: Melanie Plageman
Discussion: https://postgr.es/m/CAAKRu_bvDPJoL9mH6eYwvBpPtTGQwbDzfJbCM-OjkSZDu5yTPg@mail.gmail.com
2022-03-08 02:12:22 +01:00
|
|
|
tuplestore_putvalues(rsinfo->setResult, rsinfo->setDesc, values, nulls);
|
2021-01-13 09:33:33 +01:00
|
|
|
}
|
|
|
|
|
2021-01-17 23:46:03 +01:00
|
|
|
return (Datum) 0;
|
2021-01-13 09:33:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
gist_page_items(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
bytea *raw_page = PG_GETARG_BYTEA_P(0);
|
|
|
|
Oid indexRelid = PG_GETARG_OID(1);
|
2021-01-17 23:46:03 +01:00
|
|
|
ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
|
|
|
|
Relation indexRel;
|
pageinspect: Fix gist_page_items() with included columns
Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes. This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.
This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with. In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.
ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.
While on it, this commit fixes a third problem related to the amount of
data reported for key attributes. The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available. This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect. Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().
The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14
2023-05-19 05:38:15 +02:00
|
|
|
TupleDesc tupdesc;
|
2021-01-17 23:46:03 +01:00
|
|
|
Page page;
|
pageinspect: Fix gist_page_items() with included columns
Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes. This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.
This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with. In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.
ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.
While on it, this commit fixes a third problem related to the amount of
data reported for key attributes. The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available. This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect. Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().
The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14
2023-05-19 05:38:15 +02:00
|
|
|
uint16 flagbits;
|
|
|
|
bits16 printflags = 0;
|
2021-01-17 23:46:03 +01:00
|
|
|
OffsetNumber offset;
|
2021-02-15 04:43:25 +01:00
|
|
|
OffsetNumber maxoff = InvalidOffsetNumber;
|
pageinspect: Fix gist_page_items() with included columns
Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes. This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.
This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with. In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.
ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.
While on it, this commit fixes a third problem related to the amount of
data reported for key attributes. The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available. This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect. Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().
The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14
2023-05-19 05:38:15 +02:00
|
|
|
char *index_columns;
|
2021-01-13 09:33:33 +01:00
|
|
|
|
|
|
|
if (!superuser())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("must be superuser to use raw page functions")));
|
|
|
|
|
2022-10-18 03:22:40 +02:00
|
|
|
InitMaterializedSRF(fcinfo, 0);
|
2021-01-13 09:33:33 +01:00
|
|
|
|
2021-01-17 23:46:03 +01:00
|
|
|
/* Open the relation */
|
|
|
|
indexRel = index_open(indexRelid, AccessShareLock);
|
2021-01-13 09:33:33 +01:00
|
|
|
|
pageinspect: Fix handling of page sizes and AM types
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a sub-range, but what we are looking for is an exact
match on BLCKSZ. After considering a few options here, I have settled
down to do a generalization of get_page_from_raw(). Most of the SQL
functions already used that, and this is not strictly required if not
accessing an 8-byte-wide value from a raw page, but this feels safer in
the long run for alignment-picky environment, particularly if a code
path begins to access such values. This also reduces the number of
strings that need to be translated.
- The BRIN function brin_page_items() uses a Relation but it did not
check the access method of the opened index, potentially leading to
crashes. All the other functions in need of a Relation already did
that.
- Some code paths could fail on elog(), but we should to use ereport()
for failures that can be triggered by the user.
Tests are added to stress all the cases that are fixed as of this
commit, with some junk raw pages (\set VERBOSITY ensures that this works
across all page sizes) and unexpected index types when functions open
relations.
Author: Michael Paquier, Justin Prysby
Discussion: https://postgr.es/m/20220218030020.GA1137@telsasoft.com
Backpatch-through: 10
2022-03-16 03:19:39 +01:00
|
|
|
if (!IS_GIST(indexRel))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
errmsg("\"%s\" is not a %s index",
|
|
|
|
RelationGetRelationName(indexRel), "GiST")));
|
|
|
|
|
2023-03-02 06:03:08 +01:00
|
|
|
page = verify_gist_page(raw_page);
|
2021-01-13 09:33:33 +01:00
|
|
|
|
pageinspect: Fix handling of all-zero pages
Getting from get_raw_page() an all-zero page is considered as a valid
case by the buffer manager and it can happen for example when finding a
corrupted page with zero_damaged_pages enabled (using zero_damaged_pages
to look at corrupted pages happens), or after a crash when a relation
file is extended before any WAL for its new data is generated (before a
vacuum or autovacuum job comes in to do some cleanup).
However, all the functions of pageinspect, as of the index AMs (except
hash that has its own idea of new pages), heap, the FSM or the page
header have never worked with all-zero pages, causing various crashes
when going through the page internals.
This commit changes all the pageinspect functions to be compliant with
all-zero pages, where the choice is made to return NULL or no rows for
SRFs when finding a new page. get_raw_page() still works the same way,
returning a batch of zeros in the bytea of the page retrieved. A hard
error could be used but NULL, while more invasive, is useful when
scanning relation files in full to get a batch of results for a single
relation in one query. Tests are added for all the code paths
impacted.
Reported-by: Daria Lepikhova
Author: Michael Paquier
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
2022-04-14 08:08:03 +02:00
|
|
|
if (PageIsNew(page))
|
|
|
|
{
|
|
|
|
index_close(indexRel, AccessShareLock);
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
}
|
|
|
|
|
pageinspect: Fix gist_page_items() with included columns
Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes. This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.
This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with. In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.
ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.
While on it, this commit fixes a third problem related to the amount of
data reported for key attributes. The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available. This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect. Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().
The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14
2023-05-19 05:38:15 +02:00
|
|
|
flagbits = GistPageGetOpaque(page)->flags;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Included attributes are added when dealing with leaf pages, discarded
|
|
|
|
* for non-leaf pages as these include only data for key attributes.
|
|
|
|
*/
|
|
|
|
printflags |= RULE_INDEXDEF_PRETTY;
|
|
|
|
if (flagbits & F_LEAF)
|
|
|
|
{
|
|
|
|
tupdesc = RelationGetDescr(indexRel);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
tupdesc = CreateTupleDescCopy(RelationGetDescr(indexRel));
|
|
|
|
tupdesc->natts = IndexRelationGetNumberOfKeyAttributes(indexRel);
|
|
|
|
printflags |= RULE_INDEXDEF_KEYS_ONLY;
|
|
|
|
}
|
|
|
|
|
|
|
|
index_columns = pg_get_indexdef_columns_extended(indexRelid,
|
|
|
|
printflags);
|
|
|
|
|
2021-02-15 04:43:25 +01:00
|
|
|
/* Avoid bogus PageGetMaxOffsetNumber() call with deleted pages */
|
2021-01-17 23:46:03 +01:00
|
|
|
if (GistPageIsDeleted(page))
|
|
|
|
elog(NOTICE, "page is deleted");
|
2021-02-15 04:43:25 +01:00
|
|
|
else
|
|
|
|
maxoff = PageGetMaxOffsetNumber(page);
|
2021-01-13 09:33:33 +01:00
|
|
|
|
2021-01-17 23:46:03 +01:00
|
|
|
for (offset = FirstOffsetNumber;
|
2021-02-15 04:43:25 +01:00
|
|
|
offset <= maxoff;
|
2021-01-17 23:46:03 +01:00
|
|
|
offset++)
|
2021-01-13 09:33:33 +01:00
|
|
|
{
|
2021-02-15 05:11:11 +01:00
|
|
|
Datum values[5];
|
|
|
|
bool nulls[5];
|
2021-01-13 09:33:33 +01:00
|
|
|
ItemId id;
|
|
|
|
IndexTuple itup;
|
|
|
|
Datum itup_values[INDEX_MAX_KEYS];
|
|
|
|
bool itup_isnull[INDEX_MAX_KEYS];
|
pageinspect: Fix gist_page_items() with included columns
Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes. This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.
This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with. In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.
ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.
While on it, this commit fixes a third problem related to the amount of
data reported for key attributes. The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available. This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect. Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().
The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14
2023-05-19 05:38:15 +02:00
|
|
|
StringInfoData buf;
|
|
|
|
int i;
|
2021-01-13 09:33:33 +01:00
|
|
|
|
|
|
|
id = PageGetItemId(page, offset);
|
|
|
|
|
|
|
|
if (!ItemIdIsValid(id))
|
|
|
|
elog(ERROR, "invalid ItemId");
|
|
|
|
|
|
|
|
itup = (IndexTuple) PageGetItem(page, id);
|
|
|
|
|
pageinspect: Fix gist_page_items() with included columns
Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes. This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.
This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with. In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.
ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.
While on it, this commit fixes a third problem related to the amount of
data reported for key attributes. The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available. This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect. Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().
The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14
2023-05-19 05:38:15 +02:00
|
|
|
index_deform_tuple(itup, tupdesc,
|
2021-01-13 09:33:33 +01:00
|
|
|
itup_values, itup_isnull);
|
|
|
|
|
|
|
|
memset(nulls, 0, sizeof(nulls));
|
|
|
|
|
|
|
|
values[0] = DatumGetInt16(offset);
|
|
|
|
values[1] = ItemPointerGetDatum(&itup->t_tid);
|
|
|
|
values[2] = Int32GetDatum((int) IndexTupleSize(itup));
|
2021-02-15 05:11:11 +01:00
|
|
|
values[3] = BoolGetDatum(ItemIdIsDead(id));
|
2021-01-18 13:48:43 +01:00
|
|
|
|
pageinspect: Fix gist_page_items() with included columns
Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes. This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.
This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with. In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.
ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.
While on it, this commit fixes a third problem related to the amount of
data reported for key attributes. The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available. This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect. Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().
The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14
2023-05-19 05:38:15 +02:00
|
|
|
if (index_columns)
|
|
|
|
{
|
|
|
|
initStringInfo(&buf);
|
|
|
|
appendStringInfo(&buf, "(%s)=(", index_columns);
|
|
|
|
|
|
|
|
/* Most of this is copied from record_out(). */
|
|
|
|
for (i = 0; i < tupdesc->natts; i++)
|
|
|
|
{
|
|
|
|
char *value;
|
|
|
|
char *tmp;
|
|
|
|
bool nq = false;
|
|
|
|
|
|
|
|
if (itup_isnull[i])
|
|
|
|
value = "null";
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Oid foutoid;
|
|
|
|
bool typisvarlena;
|
|
|
|
Oid typoid;
|
|
|
|
|
|
|
|
typoid = tupdesc->attrs[i].atttypid;
|
|
|
|
getTypeOutputInfo(typoid, &foutoid, &typisvarlena);
|
|
|
|
value = OidOutputFunctionCall(foutoid, itup_values[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i == IndexRelationGetNumberOfKeyAttributes(indexRel))
|
|
|
|
appendStringInfoString(&buf, ") INCLUDE (");
|
|
|
|
else if (i > 0)
|
|
|
|
appendStringInfoString(&buf, ", ");
|
|
|
|
|
|
|
|
/* Check whether we need double quotes for this value */
|
|
|
|
nq = (value[0] == '\0'); /* force quotes for empty string */
|
|
|
|
for (tmp = value; *tmp; tmp++)
|
|
|
|
{
|
|
|
|
char ch = *tmp;
|
|
|
|
|
|
|
|
if (ch == '"' || ch == '\\' ||
|
|
|
|
ch == '(' || ch == ')' || ch == ',' ||
|
|
|
|
isspace((unsigned char) ch))
|
|
|
|
{
|
|
|
|
nq = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* And emit the string */
|
|
|
|
if (nq)
|
|
|
|
appendStringInfoCharMacro(&buf, '"');
|
|
|
|
for (tmp = value; *tmp; tmp++)
|
|
|
|
{
|
|
|
|
char ch = *tmp;
|
|
|
|
|
|
|
|
if (ch == '"' || ch == '\\')
|
|
|
|
appendStringInfoCharMacro(&buf, ch);
|
|
|
|
appendStringInfoCharMacro(&buf, ch);
|
|
|
|
}
|
|
|
|
if (nq)
|
|
|
|
appendStringInfoCharMacro(&buf, '"');
|
|
|
|
}
|
|
|
|
|
|
|
|
appendStringInfoChar(&buf, ')');
|
|
|
|
|
|
|
|
values[4] = CStringGetTextDatum(buf.data);
|
|
|
|
nulls[4] = false;
|
|
|
|
}
|
2021-01-18 13:48:43 +01:00
|
|
|
else
|
|
|
|
{
|
2021-02-15 05:11:11 +01:00
|
|
|
values[4] = (Datum) 0;
|
|
|
|
nulls[4] = true;
|
2021-01-18 13:48:43 +01:00
|
|
|
}
|
2021-01-13 09:33:33 +01:00
|
|
|
|
Simplify SRFs using materialize mode in contrib/ modules
9e98583 introduced a helper to centralize building their needed state
(tuplestore, tuple descriptors, etc.), checking for any errors. This
commit updates all places of contrib/ that can be switched to use
SetSingleFuncCall() as a drop-in replacement, resulting in the removal
of a lot of boilerplate code in all the modules updated by this commit.
Per analysis, some places remain as they are:
- pg_logdir_ls() in adminpack/ uses historically TYPEFUNC_RECORD as
return type, and I suspect that changing it may cause issues at run-time
with some of its past versions, down to 1.0.
- dblink/ uses a wrapper function doing exactly the work of
SetSingleFuncCall(). Here the switch should be possible, but rather
invasive so it does not seem the extra backpatch maintenance cost.
- tablefunc/, similarly, uses multiple helper functions with portions of
SetSingleFuncCall() spread across the code paths of this module.
Author: Melanie Plageman
Discussion: https://postgr.es/m/CAAKRu_bvDPJoL9mH6eYwvBpPtTGQwbDzfJbCM-OjkSZDu5yTPg@mail.gmail.com
2022-03-08 02:12:22 +01:00
|
|
|
tuplestore_putvalues(rsinfo->setResult, rsinfo->setDesc, values, nulls);
|
2021-01-13 09:33:33 +01:00
|
|
|
}
|
|
|
|
|
2021-01-17 23:46:03 +01:00
|
|
|
relation_close(indexRel, AccessShareLock);
|
2021-01-13 09:33:33 +01:00
|
|
|
|
2021-01-17 23:46:03 +01:00
|
|
|
return (Datum) 0;
|
2021-01-13 09:33:33 +01:00
|
|
|
}
|