|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* builtins.h
|
|
|
|
* Declarations for operations on built-in types.
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* src/include/utils/builtins.h
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef BUILTINS_H
|
|
|
|
#define BUILTINS_H
|
|
|
|
|
|
|
|
#include "fmgr.h"
|
|
|
|
#include "nodes/nodes.h"
|
|
|
|
#include "utils/fmgrprotos.h"
|
|
|
|
|
|
|
|
/* Sign + the most decimal digits an 8-byte number could have */
|
|
|
|
#define MAXINT8LEN 20
|
|
|
|
|
|
|
|
/* bool.c */
|
|
|
|
extern bool parse_bool(const char *value, bool *result);
|
|
|
|
extern bool parse_bool_with_len(const char *value, size_t len, bool *result);
|
|
|
|
|
|
|
|
/* domains.c */
|
Provide database object names as separate fields in error messages.
This patch addresses the problem that applications currently have to
extract object names from possibly-localized textual error messages,
if they want to know for example which index caused a UNIQUE_VIOLATION
failure. It adds new error message fields to the wire protocol, which
can carry the name of a table, table column, data type, or constraint
associated with the error. (Since the protocol spec has always instructed
clients to ignore unrecognized field types, this should not create any
compatibility problem.)
Support for providing these new fields has been added to just a limited set
of error reports (mainly, those in the "integrity constraint violation"
SQLSTATE class), but we will doubtless add them to more calls in future.
Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with
additional hacking by Tom Lane.
13 years ago
|
|
|
extern void domain_check(Datum value, bool isnull, Oid domainType,
|
|
|
|
void **extra, MemoryContext mcxt);
|
Provide database object names as separate fields in error messages.
This patch addresses the problem that applications currently have to
extract object names from possibly-localized textual error messages,
if they want to know for example which index caused a UNIQUE_VIOLATION
failure. It adds new error message fields to the wire protocol, which
can carry the name of a table, table column, data type, or constraint
associated with the error. (Since the protocol spec has always instructed
clients to ignore unrecognized field types, this should not create any
compatibility problem.)
Support for providing these new fields has been added to just a limited set
of error reports (mainly, those in the "integrity constraint violation"
SQLSTATE class), but we will doubtless add them to more calls in future.
Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with
additional hacking by Tom Lane.
13 years ago
|
|
|
extern int errdatatype(Oid datatypeOid);
|
|
|
|
extern int errdomainconstraint(Oid datatypeOid, const char *conname);
|
|
|
|
|
|
|
|
/* encode.c */
|
|
|
|
extern uint64 hex_encode(const char *src, size_t len, char *dst);
|
|
|
|
extern uint64 hex_decode(const char *src, size_t len, char *dst);
|
|
|
|
extern uint64 hex_decode_safe(const char *src, size_t len, char *dst,
|
|
|
|
Node *escontext);
|
|
|
|
|
|
|
|
/* int.c */
|
|
|
|
extern int2vector *buildint2vector(const int16 *int2s, int n);
|
|
|
|
|
|
|
|
/* name.c */
|
|
|
|
extern void namestrcpy(Name name, const char *str);
|
|
|
|
extern int namestrcmp(Name name, const char *str);
|
|
|
|
|
|
|
|
/* numutils.c */
|
|
|
|
extern int16 pg_strtoint16(const char *s);
|
Convert a few datatype input functions to use "soft" error reporting.
This patch converts the input functions for bool, int2, int4, int8,
float4, float8, numeric, and contrib/cube to the new soft-error style.
array_in and record_in are also converted. There's lots more to do,
but this is enough to provide proof-of-concept that the soft-error
API is usable, as well as reference examples for how to convert
input functions.
This patch is mostly by me, but it owes very substantial debt to
earlier work by Nikita Glukhov, Andrew Dunstan, and Amul Sul.
Thanks to Andres Freund for review.
Discussion: https://postgr.es/m/3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru
3 years ago
|
|
|
extern int16 pg_strtoint16_safe(const char *s, Node *escontext);
|
|
|
|
extern int32 pg_strtoint32(const char *s);
|
Convert a few datatype input functions to use "soft" error reporting.
This patch converts the input functions for bool, int2, int4, int8,
float4, float8, numeric, and contrib/cube to the new soft-error style.
array_in and record_in are also converted. There's lots more to do,
but this is enough to provide proof-of-concept that the soft-error
API is usable, as well as reference examples for how to convert
input functions.
This patch is mostly by me, but it owes very substantial debt to
earlier work by Nikita Glukhov, Andrew Dunstan, and Amul Sul.
Thanks to Andres Freund for review.
Discussion: https://postgr.es/m/3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru
3 years ago
|
|
|
extern int32 pg_strtoint32_safe(const char *s, Node *escontext);
|
|
|
|
extern int64 pg_strtoint64(const char *s);
|
Convert a few datatype input functions to use "soft" error reporting.
This patch converts the input functions for bool, int2, int4, int8,
float4, float8, numeric, and contrib/cube to the new soft-error style.
array_in and record_in are also converted. There's lots more to do,
but this is enough to provide proof-of-concept that the soft-error
API is usable, as well as reference examples for how to convert
input functions.
This patch is mostly by me, but it owes very substantial debt to
earlier work by Nikita Glukhov, Andrew Dunstan, and Amul Sul.
Thanks to Andres Freund for review.
Discussion: https://postgr.es/m/3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru
3 years ago
|
|
|
extern int64 pg_strtoint64_safe(const char *s, Node *escontext);
|
Detect bad input for types xid, xid8, and cid.
Historically these input functions just called strtoul or strtoull
and returned the result, with no error detection whatever. Upgrade
them to reject garbage input and out-of-range values, similarly to
our other numeric input routines.
To share the code for this with type oid, adjust the existing
"oidin_subr" to be agnostic about the SQL name of the type it is
handling, and move it to numutils.c; then clone it for 64-bit types.
Because the xid types previously accepted hex and octal input by
reason of calling strtoul[l] with third argument zero, I made the
common subroutine do that too, with the consequence that type oid
now also accepts hex and octal input. In view of 6fcda9aba, that
seems like a good thing.
While at it, simplify the existing over-complicated handling of
syntax errors from strtoul: we only need one ereturn not three.
Discussion: https://postgr.es/m/3526121.1672000729@sss.pgh.pa.us
3 years ago
|
|
|
extern uint32 uint32in_subr(const char *s, char **endloc,
|
|
|
|
const char *typname, Node *escontext);
|
|
|
|
extern uint64 uint64in_subr(const char *s, char **endloc,
|
|
|
|
const char *typname, Node *escontext);
|
|
|
|
extern int pg_itoa(int16 i, char *a);
|
|
|
|
extern int pg_ultoa_n(uint32 value, char *a);
|
|
|
|
extern int pg_ulltoa_n(uint64 value, char *a);
|
|
|
|
extern int pg_ltoa(int32 value, char *a);
|
|
|
|
extern int pg_lltoa(int64 value, char *a);
|
|
|
|
extern char *pg_ultostr_zeropad(char *str, uint32 value, int32 minwidth);
|
|
|
|
extern char *pg_ultostr(char *str, uint32 value);
|
|
|
|
|
|
|
|
/* oid.c */
|
|
|
|
extern oidvector *buildoidvector(const Oid *oids, int n);
|
|
|
|
extern Oid oidparse(Node *node);
|
|
|
|
extern int oid_cmp(const void *p1, const void *p2);
|
|
|
|
|
|
|
|
/* regexp.c */
|
|
|
|
extern char *regexp_fixed_prefix(text *text_re, bool case_insensitive,
|
|
|
|
Oid collation, bool *exact);
|
|
|
|
|
|
|
|
/* ruleutils.c */
|
|
|
|
extern PGDLLIMPORT bool quote_all_identifiers;
|
|
|
|
extern const char *quote_identifier(const char *ident);
|
|
|
|
extern char *quote_qualified_identifier(const char *qualifier,
|
|
|
|
const char *ident);
|
|
|
|
extern void generate_operator_clause(fmStringInfo buf,
|
|
|
|
const char *leftop, Oid leftoptype,
|
|
|
|
Oid opoid,
|
|
|
|
const char *rightop, Oid rightoptype);
|
|
|
|
|
|
|
|
/* varchar.c */
|
|
|
|
extern int bpchartruelen(char *s, int len);
|
|
|
|
|
|
|
|
/* popular functions from varlena.c */
|
|
|
|
extern text *cstring_to_text(const char *s);
|
|
|
|
extern text *cstring_to_text_with_len(const char *s, int len);
|
|
|
|
extern char *text_to_cstring(const text *t);
|
|
|
|
extern void text_to_cstring_buffer(const text *src, char *dst, size_t dst_len);
|
|
|
|
|
|
|
|
#define CStringGetTextDatum(s) PointerGetDatum(cstring_to_text(s))
|
|
|
|
#define TextDatumGetCString(d) text_to_cstring((text *) DatumGetPointer(d))
|
|
|
|
|
|
|
|
/* xid.c */
|
|
|
|
extern int xidComparator(const void *arg1, const void *arg2);
|
Fix ordering of XIDs in ProcArrayApplyRecoveryInfo
Commit 8431e296ea reworked ProcArrayApplyRecoveryInfo to sort XIDs
before adding them to KnownAssignedXids. But the XIDs are sorted using
xidComparator, which compares the XIDs simply as uint32 values, not
logically. KnownAssignedXidsAdd() however expects XIDs in logical order,
and calls TransactionIdFollowsOrEquals() to enforce that. If there are
XIDs for which the two orderings disagree, an error is raised and the
recovery fails/restarts.
Hitting this issue is fairly easy - you just need two transactions, one
started before the 4B limit (e.g. XID 4294967290), the other sometime
after it (e.g. XID 1000). Logically (4294967290 <= 1000) but when
compared using xidComparator we try to add them in the opposite order.
Which makes KnownAssignedXidsAdd() fail with an error like this:
ERROR: out-of-order XID insertion in KnownAssignedXids
This only happens during replica startup, while processing RUNNING_XACTS
records to build the snapshot. Once we reach STANDBY_SNAPSHOT_READY, we
skip these records. So this does not affect already running replicas,
but if you restart (or create) a replica while there are transactions
with XIDs for which the two orderings disagree, you may hit this.
Long-running transactions and frequent replica restarts increase the
likelihood of hitting this issue. Once the replica gets into this state,
it can't be started (even if the old transactions are terminated).
Fixed by sorting the XIDs logically - this is fine because we're dealing
with normal XIDs (because it's XIDs assigned to backends) and from the
same wraparound epoch (otherwise the backends could not be running at
the same time on the primary node). So there are no problems with the
triangle inequality, which is why xidComparator compares raw values.
Investigation and root cause analysis by Abhijit Menon-Sen. Patch by me.
This issue is present in all releases since 9.4, however releases up to
9.6 are EOL already so backpatch to 10 only.
Reviewed-by: Abhijit Menon-Sen
Reviewed-by: Alvaro Herrera
Backpatch-through: 10
Discussion: https://postgr.es/m/36b8a501-5d73-277c-4972-f58a4dce088a%40enterprisedb.com
3 years ago
|
|
|
extern int xidLogicalComparator(const void *arg1, const void *arg2);
|
|
|
|
|
|
|
|
/* inet_cidr_ntop.c */
|
|
|
|
extern char *pg_inet_cidr_ntop(int af, const void *src, int bits,
|
|
|
|
char *dst, size_t size);
|
|
|
|
|
|
|
|
/* inet_net_pton.c */
|
|
|
|
extern int pg_inet_net_pton(int af, const char *src,
|
|
|
|
void *dst, size_t size);
|
|
|
|
|
|
|
|
/* network.c */
|
Fix assorted issues in convert_to_scalar().
If convert_to_scalar is passed a pair of datatypes it can't cope with,
its former behavior was just to elog(ERROR). While this is OK so far as
the core code is concerned, there's extension code that would like to use
scalarltsel/scalargtsel/etc as selectivity estimators for operators that
work on non-core datatypes, and this behavior is a show-stopper for that
use-case. If we simply allow convert_to_scalar to return FALSE instead of
outright failing, then the main logic of scalarltsel/scalargtsel will work
fine for any operator that behaves like a scalar inequality comparison.
The lack of conversion capability will mean that we can't estimate to
better than histogram-bin-width precision, since the code will effectively
assume that the comparison constant falls at the middle of its bin. But
that's still a lot better than nothing. (Someday we should provide a way
for extension code to supply a custom version of convert_to_scalar, but
today is not that day.)
While poking at this issue, we noted that the existing code for handling
type bytea in convert_to_scalar is several bricks shy of a load.
It assumes without checking that if the comparison value is type bytea,
the bounds values are too; in the worst case this could lead to a crash.
It also fails to detoast the input values, so that the comparison result is
complete garbage if any input is toasted out-of-line, compressed, or even
just short-header. I'm not sure how often such cases actually occur ---
the bounds values, at least, are probably safe since they are elements of
an array and hence can't be toasted. But that doesn't make this code OK.
Back-patch to all supported branches, partly because author requested that,
but mostly because of the bytea bugs. The change in API for the exposed
routine convert_network_to_scalar() is theoretically a back-patch hazard,
but it seems pretty unlikely that any third-party code is calling that
function directly.
Tomas Vondra, with some adjustments by me
Discussion: https://postgr.es/m/b68441b6-d18f-13ab-b43b-9a72188a4e02@2ndquadrant.com
7 years ago
|
|
|
extern double convert_network_to_scalar(Datum value, Oid typid, bool *failure);
|
|
|
|
extern Datum network_scan_first(Datum in);
|
|
|
|
extern Datum network_scan_last(Datum in);
|
|
|
|
extern void clean_ipv6_addr(int addr_family, char *addr);
|
|
|
|
|
|
|
|
/* numeric.c */
|
|
|
|
extern Datum numeric_float8_no_overflow(PG_FUNCTION_ARGS);
|
|
|
|
|
|
|
|
/* format_type.c */
|
|
|
|
|
|
|
|
/* Control flags for format_type_extended */
|
|
|
|
#define FORMAT_TYPE_TYPEMOD_GIVEN 0x01 /* typemod defined by caller */
|
|
|
|
#define FORMAT_TYPE_ALLOW_INVALID 0x02 /* allow invalid types */
|
|
|
|
#define FORMAT_TYPE_FORCE_QUALIFY 0x04 /* force qualification of type */
|
|
|
|
#define FORMAT_TYPE_INVALID_AS_NULL 0x08 /* NULL if undefined */
|
|
|
|
extern char *format_type_extended(Oid type_oid, int32 typemod, bits16 flags);
|
|
|
|
|
|
|
|
extern char *format_type_be(Oid type_oid);
|
|
|
|
extern char *format_type_be_qualified(Oid type_oid);
|
|
|
|
extern char *format_type_with_typemod(Oid type_oid, int32 typemod);
|
|
|
|
|
|
|
|
extern int32 type_maximum_size(Oid type_oid, int32 typemod);
|
|
|
|
|
|
|
|
/* quote.c */
|
|
|
|
extern char *quote_literal_cstr(const char *rawstr);
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
8 years ago
|
|
|
#endif /* BUILTINS_H */
|