1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* parse_node.c
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
* various routines that make nodes for querytrees
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/parser/parse_node.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
2002-03-12 01:52:10 +01:00
|
|
|
#include "postgres.h"
|
|
|
|
|
2012-08-30 22:15:44 +02:00
|
|
|
#include "access/htup_details.h"
|
2019-01-21 19:18:20 +01:00
|
|
|
#include "access/table.h"
|
1997-11-25 23:07:18 +01:00
|
|
|
#include "catalog/pg_type.h"
|
2006-03-14 23:48:25 +01:00
|
|
|
#include "mb/pg_wchar.h"
|
1997-11-25 23:07:18 +01:00
|
|
|
#include "nodes/makefuncs.h"
|
2008-08-26 00:42:34 +02:00
|
|
|
#include "nodes/nodeFuncs.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "parser/parse_coerce.h"
|
1997-11-25 23:07:18 +01:00
|
|
|
#include "parser/parse_expr.h"
|
|
|
|
#include "parser/parse_relation.h"
|
2019-11-12 04:00:16 +01:00
|
|
|
#include "parser/parsetree.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "utils/builtins.h"
|
2011-09-09 19:23:41 +02:00
|
|
|
#include "utils/int8.h"
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
#include "utils/lsyscache.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "utils/syscache.h"
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
#include "utils/varbit.h"
|
2000-02-24 02:59:17 +01:00
|
|
|
|
2008-09-01 22:42:46 +02:00
|
|
|
static void pcb_error_callback(void *arg);
|
|
|
|
|
|
|
|
|
2007-06-24 00:12:52 +02:00
|
|
|
/*
|
|
|
|
* make_parsestate
|
|
|
|
* Allocate and initialize a new ParseState.
|
|
|
|
*
|
|
|
|
* Caller should eventually release the ParseState via free_parsestate().
|
1996-10-30 03:02:41 +01:00
|
|
|
*/
|
1997-11-25 23:07:18 +01:00
|
|
|
ParseState *
|
1998-01-19 06:06:41 +01:00
|
|
|
make_parsestate(ParseState *parentParseState)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-11-25 23:07:18 +01:00
|
|
|
ParseState *pstate;
|
|
|
|
|
2002-11-13 01:39:48 +01:00
|
|
|
pstate = palloc0(sizeof(ParseState));
|
1998-01-17 05:53:46 +01:00
|
|
|
|
1998-01-19 06:06:41 +01:00
|
|
|
pstate->parentParseState = parentParseState;
|
2003-04-30 00:13:11 +02:00
|
|
|
|
|
|
|
/* Fill in fields that don't start at null/false/zero */
|
|
|
|
pstate->p_next_resno = 1;
|
Change unknown-type literals to type text in SELECT and RETURNING lists.
Previously, we left such literals alone if the query or subquery had
no properties forcing a type decision to be made (such as an ORDER BY or
DISTINCT clause using that output column). This meant that "unknown" could
be an exposed output column type, which has never been a great idea because
it could result in strange failures later on. For example, an outer query
that tried to do any operations on an unknown-type subquery output would
generally fail with some weird error like "failed to find conversion
function from unknown to text" or "could not determine which collation to
use for string comparison". Also, if the case occurred in a CREATE VIEW's
query then the view would have an unknown-type column, causing similar
failures in queries trying to use the view.
To fix, at the tail end of parse analysis of a query, forcibly convert any
remaining "unknown" literals in its SELECT or RETURNING list to type text.
However, provide a switch to suppress that, and use it in the cases of
SELECT inside a set operation or INSERT command. In those cases we already
had type resolution rules that make use of context information from outside
the subquery proper, and we don't want to change that behavior.
Also, change creation of an unknown-type column in a relation from a
warning to a hard error. The error should be unreachable now in CREATE
VIEW or CREATE MATVIEW, but it's still possible to explicitly say "unknown"
in CREATE TABLE or CREATE (composite) TYPE. We want to forbid that because
it's nothing but a foot-gun.
This change creates a pg_upgrade failure case: a matview that contains an
unknown-type column can't be pg_upgraded, because reparsing the matview's
defining query will now decide that the column is of type text, which
doesn't match the cstring-like storage that the old materialized column
would actually have. Add a checking pass to detect that. While at it,
we can detect tables or composite types that would fail, essentially
for free. Those would fail safely anyway later on, but we might as
well fail earlier.
This patch is by me, but it owes something to previous investigations
by Rahila Syed. Also thanks to Ashutosh Bapat and Michael Paquier for
review.
Discussion: https://postgr.es/m/CAH2L28uwwbL9HUM-WR=hromW1Cvamkn7O-g8fPY2m=_7muJ0oA@mail.gmail.com
2017-01-25 15:17:18 +01:00
|
|
|
pstate->p_resolve_unknowns = true;
|
2003-04-30 00:13:11 +02:00
|
|
|
|
|
|
|
if (parentParseState)
|
2006-03-14 23:48:25 +01:00
|
|
|
{
|
|
|
|
pstate->p_sourcetext = parentParseState->p_sourcetext;
|
2009-10-31 02:41:31 +01:00
|
|
|
/* all hooks are copied from parent */
|
|
|
|
pstate->p_pre_columnref_hook = parentParseState->p_pre_columnref_hook;
|
|
|
|
pstate->p_post_columnref_hook = parentParseState->p_post_columnref_hook;
|
|
|
|
pstate->p_paramref_hook = parentParseState->p_paramref_hook;
|
|
|
|
pstate->p_coerce_param_hook = parentParseState->p_coerce_param_hook;
|
|
|
|
pstate->p_ref_hook_state = parentParseState->p_ref_hook_state;
|
2017-04-01 06:17:18 +02:00
|
|
|
/* query environment stays in context for the whole parse analysis */
|
|
|
|
pstate->p_queryEnv = parentParseState->p_queryEnv;
|
2006-03-14 23:48:25 +01:00
|
|
|
}
|
1998-02-26 05:46:47 +01:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return pstate;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2007-06-24 00:12:52 +02:00
|
|
|
/*
|
|
|
|
* free_parsestate
|
|
|
|
* Release a ParseState and any subsidiary resources.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
free_parsestate(ParseState *pstate)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Check that we did not produce too many resnos; at the very least we
|
|
|
|
* cannot allow more than 2^16, since that would exceed the range of a
|
|
|
|
* AttrNumber. It seems safest to use MaxTupleAttributeNumber.
|
|
|
|
*/
|
|
|
|
if (pstate->p_next_resno - 1 > MaxTupleAttributeNumber)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("target lists can have at most %d entries",
|
|
|
|
MaxTupleAttributeNumber)));
|
|
|
|
|
|
|
|
if (pstate->p_target_relation != NULL)
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(pstate->p_target_relation, NoLock);
|
2007-06-24 00:12:52 +02:00
|
|
|
|
|
|
|
pfree(pstate);
|
|
|
|
}
|
|
|
|
|
1998-05-10 01:31:34 +02:00
|
|
|
|
2006-03-14 23:48:25 +01:00
|
|
|
/*
|
|
|
|
* parser_errposition
|
|
|
|
* Report a parse-analysis-time cursor position, if possible.
|
|
|
|
*
|
|
|
|
* This is expected to be used within an ereport() call. The return value
|
|
|
|
* is a dummy (always 0, in fact).
|
|
|
|
*
|
|
|
|
* The locations stored in raw parsetrees are byte offsets into the source
|
2014-05-06 18:12:18 +02:00
|
|
|
* string. We have to convert them to 1-based character indexes for reporting
|
|
|
|
* to clients. (We do things this way to avoid unnecessary overhead in the
|
2006-03-14 23:48:25 +01:00
|
|
|
* normal non-error case: computing character indexes would be much more
|
|
|
|
* expensive than storing token offsets.)
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
parser_errposition(ParseState *pstate, int location)
|
|
|
|
{
|
2006-10-04 02:30:14 +02:00
|
|
|
int pos;
|
2006-03-14 23:48:25 +01:00
|
|
|
|
|
|
|
/* No-op if location was not provided */
|
|
|
|
if (location < 0)
|
|
|
|
return 0;
|
|
|
|
/* Can't do anything if source text is not available */
|
|
|
|
if (pstate == NULL || pstate->p_sourcetext == NULL)
|
|
|
|
return 0;
|
|
|
|
/* Convert offset to character number */
|
|
|
|
pos = pg_mbstrlen_with_len(pstate->p_sourcetext, location) + 1;
|
|
|
|
/* And pass it to the ereport mechanism */
|
|
|
|
return errposition(pos);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-09-01 22:42:46 +02:00
|
|
|
/*
|
|
|
|
* setup_parser_errposition_callback
|
|
|
|
* Arrange for non-parser errors to report an error position
|
|
|
|
*
|
|
|
|
* Sometimes the parser calls functions that aren't part of the parser
|
|
|
|
* subsystem and can't reasonably be passed a ParseState; yet we would
|
|
|
|
* like any errors thrown in those functions to be tagged with a parse
|
2014-05-06 18:12:18 +02:00
|
|
|
* error location. Use this function to set up an error context stack
|
2008-09-01 22:42:46 +02:00
|
|
|
* entry that will accomplish that. Usage pattern:
|
|
|
|
*
|
|
|
|
* declare a local variable "ParseCallbackState pcbstate"
|
|
|
|
* ...
|
|
|
|
* setup_parser_errposition_callback(&pcbstate, pstate, location);
|
|
|
|
* call function that might throw error;
|
|
|
|
* cancel_parser_errposition_callback(&pcbstate);
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
setup_parser_errposition_callback(ParseCallbackState *pcbstate,
|
|
|
|
ParseState *pstate, int location)
|
|
|
|
{
|
|
|
|
/* Setup error traceback support for ereport() */
|
|
|
|
pcbstate->pstate = pstate;
|
|
|
|
pcbstate->location = location;
|
2012-11-12 14:10:24 +01:00
|
|
|
pcbstate->errcallback.callback = pcb_error_callback;
|
|
|
|
pcbstate->errcallback.arg = (void *) pcbstate;
|
|
|
|
pcbstate->errcallback.previous = error_context_stack;
|
|
|
|
error_context_stack = &pcbstate->errcallback;
|
2008-09-01 22:42:46 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Cancel a previously-set-up errposition callback.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
cancel_parser_errposition_callback(ParseCallbackState *pcbstate)
|
|
|
|
{
|
|
|
|
/* Pop the error context stack */
|
2012-11-12 14:10:24 +01:00
|
|
|
error_context_stack = pcbstate->errcallback.previous;
|
2008-09-01 22:42:46 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Error context callback for inserting parser error location.
|
|
|
|
*
|
|
|
|
* Note that this will be called for *any* error occurring while the
|
|
|
|
* callback is installed. We avoid inserting an irrelevant error location
|
|
|
|
* if the error is a query cancel --- are there any other important cases?
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
pcb_error_callback(void *arg)
|
|
|
|
{
|
|
|
|
ParseCallbackState *pcbstate = (ParseCallbackState *) arg;
|
|
|
|
|
|
|
|
if (geterrcode() != ERRCODE_QUERY_CANCELED)
|
|
|
|
(void) parser_errposition(pcbstate->pstate, pcbstate->location);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
/*
|
2019-02-01 16:50:32 +01:00
|
|
|
* transformContainerType()
|
|
|
|
* Identify the types involved in a subscripting operation for container
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
*
|
2019-02-01 16:50:32 +01:00
|
|
|
*
|
|
|
|
* On entry, containerType/containerTypmod identify the type of the input value
|
|
|
|
* to be subscripted (which could be a domain type). These are modified if
|
|
|
|
* necessary to identify the actual container type and typmod, and the
|
|
|
|
* container's element type is returned. An error is thrown if the input isn't
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
* an array type.
|
2004-06-09 21:08:20 +02:00
|
|
|
*/
|
|
|
|
Oid
|
2019-02-01 16:50:32 +01:00
|
|
|
transformContainerType(Oid *containerType, int32 *containerTypmod)
|
2004-06-09 21:08:20 +02:00
|
|
|
{
|
2019-02-01 16:50:32 +01:00
|
|
|
Oid origContainerType = *containerType;
|
2004-06-09 21:08:20 +02:00
|
|
|
Oid elementType;
|
2019-02-01 16:50:32 +01:00
|
|
|
HeapTuple type_tuple_container;
|
|
|
|
Form_pg_type type_struct_container;
|
2004-06-09 21:08:20 +02:00
|
|
|
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
/*
|
|
|
|
* If the input is a domain, smash to base type, and extract the actual
|
2019-02-01 16:50:32 +01:00
|
|
|
* typmod to be applied to the base type. Subscripting a domain is an
|
|
|
|
* operation that necessarily works on the base container type, not the
|
|
|
|
* domain itself. (Note that we provide no method whereby the creator of a
|
|
|
|
* domain over a container type could hide its ability to be subscripted.)
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
*/
|
2019-02-01 16:50:32 +01:00
|
|
|
*containerType = getBaseTypeAndTypmod(*containerType, containerTypmod);
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
|
Fix array slicing of int2vector and oidvector values.
The previous coding labeled expressions such as pg_index.indkey[1:3] as
being of int2vector type; which is not right because the subscript bounds
of such a result don't, in general, satisfy the restrictions of int2vector.
To fix, implicitly promote the result of slicing int2vector to int2[],
or oidvector to oid[]. This is similar to what we've done with domains
over arrays, which is a good analogy because these types are very much
like restricted domains of the corresponding regular-array types.
A side-effect is that we now also forbid array-element updates on such
columns, eg while "update pg_index set indkey[4] = 42" would have worked
before if you were superuser (and corrupted your catalogs irretrievably,
no doubt) it's now disallowed. This seems like a good thing since, again,
some choices of subscripting would've led to results not satisfying the
restrictions of int2vector. The case of an array-slice update was
rejected before, though with a different error message than you get now.
We could make these cases work in future if we added a cast from int2[]
to int2vector (with a cast function checking the subscript restrictions)
but it seems unlikely that there's any value in that.
Per report from Ronan Dunklau. Back-patch to all supported branches
because of the crash risks involved.
2013-11-24 02:03:56 +01:00
|
|
|
/*
|
2019-02-01 16:50:32 +01:00
|
|
|
* Here is an array specific code. We treat int2vector and oidvector as
|
|
|
|
* though they were domains over int2[] and oid[]. This is needed because
|
|
|
|
* array slicing could create an array that doesn't satisfy the
|
|
|
|
* dimensionality constraints of the xxxvector type; so we want the result
|
|
|
|
* of a slice operation to be considered to be of the more general type.
|
Fix array slicing of int2vector and oidvector values.
The previous coding labeled expressions such as pg_index.indkey[1:3] as
being of int2vector type; which is not right because the subscript bounds
of such a result don't, in general, satisfy the restrictions of int2vector.
To fix, implicitly promote the result of slicing int2vector to int2[],
or oidvector to oid[]. This is similar to what we've done with domains
over arrays, which is a good analogy because these types are very much
like restricted domains of the corresponding regular-array types.
A side-effect is that we now also forbid array-element updates on such
columns, eg while "update pg_index set indkey[4] = 42" would have worked
before if you were superuser (and corrupted your catalogs irretrievably,
no doubt) it's now disallowed. This seems like a good thing since, again,
some choices of subscripting would've led to results not satisfying the
restrictions of int2vector. The case of an array-slice update was
rejected before, though with a different error message than you get now.
We could make these cases work in future if we added a cast from int2[]
to int2vector (with a cast function checking the subscript restrictions)
but it seems unlikely that there's any value in that.
Per report from Ronan Dunklau. Back-patch to all supported branches
because of the crash risks involved.
2013-11-24 02:03:56 +01:00
|
|
|
*/
|
2019-02-01 16:50:32 +01:00
|
|
|
if (*containerType == INT2VECTOROID)
|
|
|
|
*containerType = INT2ARRAYOID;
|
|
|
|
else if (*containerType == OIDVECTOROID)
|
|
|
|
*containerType = OIDARRAYOID;
|
Fix array slicing of int2vector and oidvector values.
The previous coding labeled expressions such as pg_index.indkey[1:3] as
being of int2vector type; which is not right because the subscript bounds
of such a result don't, in general, satisfy the restrictions of int2vector.
To fix, implicitly promote the result of slicing int2vector to int2[],
or oidvector to oid[]. This is similar to what we've done with domains
over arrays, which is a good analogy because these types are very much
like restricted domains of the corresponding regular-array types.
A side-effect is that we now also forbid array-element updates on such
columns, eg while "update pg_index set indkey[4] = 42" would have worked
before if you were superuser (and corrupted your catalogs irretrievably,
no doubt) it's now disallowed. This seems like a good thing since, again,
some choices of subscripting would've led to results not satisfying the
restrictions of int2vector. The case of an array-slice update was
rejected before, though with a different error message than you get now.
We could make these cases work in future if we added a cast from int2[]
to int2vector (with a cast function checking the subscript restrictions)
but it seems unlikely that there's any value in that.
Per report from Ronan Dunklau. Back-patch to all supported branches
because of the crash risks involved.
2013-11-24 02:03:56 +01:00
|
|
|
|
2019-02-01 16:50:32 +01:00
|
|
|
/* Get the type tuple for the container */
|
|
|
|
type_tuple_container = SearchSysCache1(TYPEOID, ObjectIdGetDatum(*containerType));
|
|
|
|
if (!HeapTupleIsValid(type_tuple_container))
|
|
|
|
elog(ERROR, "cache lookup failed for type %u", *containerType);
|
|
|
|
type_struct_container = (Form_pg_type) GETSTRUCT(type_tuple_container);
|
2004-06-09 21:08:20 +02:00
|
|
|
|
|
|
|
/* needn't check typisdefined since this will fail anyway */
|
|
|
|
|
2019-02-01 16:50:32 +01:00
|
|
|
elementType = type_struct_container->typelem;
|
2004-06-09 21:08:20 +02:00
|
|
|
if (elementType == InvalidOid)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DATATYPE_MISMATCH),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("cannot subscript type %s because it is not an array",
|
2019-02-01 16:50:32 +01:00
|
|
|
format_type_be(origContainerType))));
|
2004-06-09 21:08:20 +02:00
|
|
|
|
2019-02-01 16:50:32 +01:00
|
|
|
ReleaseSysCache(type_tuple_container);
|
2004-06-09 21:08:20 +02:00
|
|
|
|
|
|
|
return elementType;
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2019-02-01 16:50:32 +01:00
|
|
|
* transformContainerSubscripts()
|
|
|
|
* Transform container (array, etc) subscripting. This is used for both
|
|
|
|
* container fetch and container assignment.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2019-02-01 16:50:32 +01:00
|
|
|
* In a container fetch, we are given a source container value and we produce
|
|
|
|
* an expression that represents the result of extracting a single container
|
|
|
|
* element or a container slice.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2019-02-01 16:50:32 +01:00
|
|
|
* In a container assignment, we are given a destination container value plus a
|
|
|
|
* source value that is to be assigned to a single element or a slice of that
|
|
|
|
* container. We produce an expression that represents the new container value
|
|
|
|
* with the source data inserted into the right part of the container.
|
1999-07-19 02:26:20 +02:00
|
|
|
*
|
2019-02-01 16:50:32 +01:00
|
|
|
* For both cases, if the source container is of a domain-over-array type,
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
* the result is of the base array type or its element type; essentially,
|
|
|
|
* we must fold a domain to its base type before applying subscripting.
|
Fix array slicing of int2vector and oidvector values.
The previous coding labeled expressions such as pg_index.indkey[1:3] as
being of int2vector type; which is not right because the subscript bounds
of such a result don't, in general, satisfy the restrictions of int2vector.
To fix, implicitly promote the result of slicing int2vector to int2[],
or oidvector to oid[]. This is similar to what we've done with domains
over arrays, which is a good analogy because these types are very much
like restricted domains of the corresponding regular-array types.
A side-effect is that we now also forbid array-element updates on such
columns, eg while "update pg_index set indkey[4] = 42" would have worked
before if you were superuser (and corrupted your catalogs irretrievably,
no doubt) it's now disallowed. This seems like a good thing since, again,
some choices of subscripting would've led to results not satisfying the
restrictions of int2vector. The case of an array-slice update was
rejected before, though with a different error message than you get now.
We could make these cases work in future if we added a cast from int2[]
to int2vector (with a cast function checking the subscript restrictions)
but it seems unlikely that there's any value in that.
Per report from Ronan Dunklau. Back-patch to all supported branches
because of the crash risks involved.
2013-11-24 02:03:56 +01:00
|
|
|
* (Note that int2vector and oidvector are treated as domains here.)
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
*
|
2019-02-01 16:50:32 +01:00
|
|
|
* pstate Parse state
|
|
|
|
* containerBase Already-transformed expression for the container as a whole
|
|
|
|
* containerType OID of container's datatype (should match type of
|
|
|
|
* containerBase, or be the base type of containerBase's
|
|
|
|
* domain type)
|
|
|
|
* elementType OID of container's element type (fetch with
|
|
|
|
* transformContainerType, or pass InvalidOid to do it here)
|
|
|
|
* containerTypMod typmod for the container (which is also typmod for the
|
|
|
|
* elements)
|
|
|
|
* indirection Untransformed list of subscripts (must not be NIL)
|
|
|
|
* assignFrom NULL for container fetch, else transformed expression for
|
|
|
|
* source.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2019-02-01 16:50:32 +01:00
|
|
|
SubscriptingRef *
|
|
|
|
transformContainerSubscripts(ParseState *pstate,
|
|
|
|
Node *containerBase,
|
|
|
|
Oid containerType,
|
|
|
|
Oid elementType,
|
|
|
|
int32 containerTypMod,
|
|
|
|
List *indirection,
|
|
|
|
Node *assignFrom)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2004-06-09 21:08:20 +02:00
|
|
|
bool isSlice = false;
|
1997-09-08 04:41:22 +02:00
|
|
|
List *upperIndexpr = NIL;
|
|
|
|
List *lowerIndexpr = NIL;
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *idx;
|
2019-02-01 16:50:32 +01:00
|
|
|
SubscriptingRef *sbsref;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
/*
|
|
|
|
* Caller may or may not have bothered to determine elementType. Note
|
2019-02-01 16:50:32 +01:00
|
|
|
* that if the caller did do so, containerType/containerTypMod must be as
|
|
|
|
* modified by transformContainerType, ie, smash domain to base type.
|
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
|
|
|
*/
|
2004-06-09 21:08:20 +02:00
|
|
|
if (!OidIsValid(elementType))
|
2019-02-01 16:50:32 +01:00
|
|
|
elementType = transformContainerType(&containerType, &containerTypMod);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-07-19 02:26:20 +02:00
|
|
|
/*
|
2019-02-01 16:50:32 +01:00
|
|
|
* A list containing only simple subscripts refers to a single container
|
2015-12-23 03:05:16 +01:00
|
|
|
* element. If any of the items are slice specifiers (lower:upper), then
|
2019-02-01 16:50:32 +01:00
|
|
|
* the subscript expression means a container slice operation. In this
|
|
|
|
* case, we convert any non-slice items to slices by treating the single
|
2015-12-23 03:05:16 +01:00
|
|
|
* subscript as the upper bound and supplying an assumed lower bound of 1.
|
|
|
|
* We have to prescan the list to see if there are any slice items.
|
1999-07-19 02:26:20 +02:00
|
|
|
*/
|
2004-06-09 21:08:20 +02:00
|
|
|
foreach(idx, indirection)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2004-06-09 21:08:20 +02:00
|
|
|
A_Indices *ai = (A_Indices *) lfirst(idx);
|
2000-04-12 19:17:23 +02:00
|
|
|
|
2015-12-23 03:05:16 +01:00
|
|
|
if (ai->is_slice)
|
2004-06-09 21:08:20 +02:00
|
|
|
{
|
|
|
|
isSlice = true;
|
|
|
|
break;
|
1999-07-19 02:26:20 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
1999-07-19 02:26:20 +02:00
|
|
|
* Transform the subscript expressions.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-04-12 19:17:23 +02:00
|
|
|
foreach(idx, indirection)
|
1999-07-19 02:26:20 +02:00
|
|
|
{
|
Improve castNode notation by introducing list-extraction-specific variants.
This extends the castNode() notation introduced by commit 5bcab1114 to
provide, in one step, extraction of a list cell's pointer and coercion to
a concrete node type. For example, "lfirst_node(Foo, lc)" is the same
as "castNode(Foo, lfirst(lc))". Almost half of the uses of castNode
that have appeared so far include a list extraction call, so this is
pretty widely useful, and it saves a few more keystrokes compared to the
old way.
As with the previous patch, back-patch the addition of these macros to
pg_list.h, so that the notation will be available when back-patching.
Patch by me, after an idea of Andrew Gierth's.
Discussion: https://postgr.es/m/14197.1491841216@sss.pgh.pa.us
2017-04-10 19:51:29 +02:00
|
|
|
A_Indices *ai = lfirst_node(A_Indices, idx);
|
2015-12-18 19:35:22 +01:00
|
|
|
Node *subexpr;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-07-19 02:26:20 +02:00
|
|
|
if (isSlice)
|
|
|
|
{
|
|
|
|
if (ai->lidx)
|
|
|
|
{
|
Centralize the logic for detecting misplaced aggregates, window funcs, etc.
Formerly we relied on checking after-the-fact to see if an expression
contained aggregates, window functions, or sub-selects when it shouldn't.
This is grotty, easily forgotten (indeed, we had forgotten to teach
DefineIndex about rejecting window functions), and none too efficient
since it requires extra traversals of the parse tree. To improve matters,
define an enum type that classifies all SQL sub-expressions, store it in
ParseState to show what kind of expression we are currently parsing, and
make transformAggregateCall, transformWindowFuncCall, and transformSubLink
check the expression type and throw error if the type indicates the
construct is disallowed. This allows removal of a large number of ad-hoc
checks scattered around the code base. The enum type is sufficiently
fine-grained that we can still produce error messages of at least the
same specificity as before.
Bringing these error checks together revealed that we'd been none too
consistent about phrasing of the error messages, so standardize the wording
a bit.
Also, rewrite checking of aggregate arguments so that it requires only one
traversal of the arguments, rather than up to three as before.
In passing, clean up some more comments left over from add_missing_from
support, and annotate some tests that I think are dead code now that that's
gone. (I didn't risk actually removing said dead code, though.)
2012-08-10 17:35:33 +02:00
|
|
|
subexpr = transformExpr(pstate, ai->lidx, pstate->p_expr_kind);
|
1999-07-19 02:26:20 +02:00
|
|
|
/* If it's not int4 already, try to coerce */
|
2003-04-30 00:13:11 +02:00
|
|
|
subexpr = coerce_to_target_type(pstate,
|
2005-10-15 04:49:52 +02:00
|
|
|
subexpr, exprType(subexpr),
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
INT4OID, -1,
|
|
|
|
COERCION_ASSIGNMENT,
|
2008-08-29 01:09:48 +02:00
|
|
|
COERCE_IMPLICIT_CAST,
|
|
|
|
-1);
|
1999-07-19 02:26:20 +02:00
|
|
|
if (subexpr == NULL)
|
2003-07-19 22:20:53 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DATATYPE_MISMATCH),
|
2008-08-29 01:09:48 +02:00
|
|
|
errmsg("array subscript must have type integer"),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
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
2017-06-21 21:35:54 +02:00
|
|
|
parser_errposition(pstate, exprLocation(ai->lidx))));
|
1999-07-19 02:26:20 +02:00
|
|
|
}
|
2015-12-23 03:05:16 +01:00
|
|
|
else if (!ai->is_slice)
|
1999-07-19 02:26:20 +02:00
|
|
|
{
|
|
|
|
/* Make a constant 1 */
|
|
|
|
subexpr = (Node *) makeConst(INT4OID,
|
2007-03-17 01:11:05 +01:00
|
|
|
-1,
|
2011-03-26 01:10:42 +01:00
|
|
|
InvalidOid,
|
1999-07-19 02:26:20 +02:00
|
|
|
sizeof(int32),
|
|
|
|
Int32GetDatum(1),
|
|
|
|
false,
|
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
2017-06-21 21:18:54 +02:00
|
|
|
true); /* pass by value */
|
1999-07-19 02:26:20 +02:00
|
|
|
}
|
2015-12-23 03:05:16 +01:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Slice with omitted lower bound, put NULL into the list */
|
|
|
|
subexpr = NULL;
|
|
|
|
}
|
1999-07-19 02:26:20 +02:00
|
|
|
lowerIndexpr = lappend(lowerIndexpr, subexpr);
|
|
|
|
}
|
2015-12-23 03:05:16 +01:00
|
|
|
else
|
|
|
|
Assert(ai->lidx == NULL && !ai->is_slice);
|
|
|
|
|
|
|
|
if (ai->uidx)
|
|
|
|
{
|
|
|
|
subexpr = transformExpr(pstate, ai->uidx, pstate->p_expr_kind);
|
|
|
|
/* If it's not int4 already, try to coerce */
|
|
|
|
subexpr = coerce_to_target_type(pstate,
|
|
|
|
subexpr, exprType(subexpr),
|
|
|
|
INT4OID, -1,
|
|
|
|
COERCION_ASSIGNMENT,
|
|
|
|
COERCE_IMPLICIT_CAST,
|
|
|
|
-1);
|
|
|
|
if (subexpr == NULL)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DATATYPE_MISMATCH),
|
|
|
|
errmsg("array subscript must have type integer"),
|
|
|
|
parser_errposition(pstate, exprLocation(ai->uidx))));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Slice with omitted upper bound, put NULL into the list */
|
|
|
|
Assert(isSlice && ai->is_slice);
|
|
|
|
subexpr = NULL;
|
|
|
|
}
|
1999-07-19 02:26:20 +02:00
|
|
|
upperIndexpr = lappend(upperIndexpr, subexpr);
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-07-19 02:26:20 +02:00
|
|
|
/*
|
|
|
|
* If doing an array store, coerce the source value to the right type.
|
2006-08-02 03:59:48 +02:00
|
|
|
* (This should agree with the coercion done by transformAssignedExpr.)
|
1999-07-19 02:26:20 +02:00
|
|
|
*/
|
|
|
|
if (assignFrom != NULL)
|
|
|
|
{
|
|
|
|
Oid typesource = exprType(assignFrom);
|
2019-02-01 16:50:32 +01:00
|
|
|
Oid typeneeded = isSlice ? containerType : elementType;
|
2008-08-29 01:09:48 +02:00
|
|
|
Node *newFrom;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2008-08-29 01:09:48 +02:00
|
|
|
newFrom = coerce_to_target_type(pstate,
|
|
|
|
assignFrom, typesource,
|
2019-02-01 16:50:32 +01:00
|
|
|
typeneeded, containerTypMod,
|
2008-08-29 01:09:48 +02:00
|
|
|
COERCION_ASSIGNMENT,
|
|
|
|
COERCE_IMPLICIT_CAST,
|
|
|
|
-1);
|
|
|
|
if (newFrom == NULL)
|
2004-06-09 21:08:20 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DATATYPE_MISMATCH),
|
|
|
|
errmsg("array assignment requires type %s"
|
|
|
|
" but expression is of type %s",
|
|
|
|
format_type_be(typeneeded),
|
|
|
|
format_type_be(typesource)),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
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
2017-06-21 21:35:54 +02:00
|
|
|
errhint("You will need to rewrite or cast the expression."),
|
2008-08-29 01:09:48 +02:00
|
|
|
parser_errposition(pstate, exprLocation(assignFrom))));
|
|
|
|
assignFrom = newFrom;
|
1999-07-19 02:26:20 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-07-19 02:26:20 +02:00
|
|
|
/*
|
2019-02-01 16:50:32 +01:00
|
|
|
* Ready to build the SubscriptingRef node.
|
1999-07-19 02:26:20 +02:00
|
|
|
*/
|
2019-02-01 16:50:32 +01:00
|
|
|
sbsref = (SubscriptingRef *) makeNode(SubscriptingRef);
|
|
|
|
if (assignFrom != NULL)
|
|
|
|
sbsref->refassgnexpr = (Expr *) assignFrom;
|
|
|
|
|
|
|
|
sbsref->refcontainertype = containerType;
|
|
|
|
sbsref->refelemtype = elementType;
|
|
|
|
sbsref->reftypmod = containerTypMod;
|
2011-03-20 01:29:08 +01:00
|
|
|
/* refcollid will be set by parse_collate.c */
|
2019-02-01 16:50:32 +01:00
|
|
|
sbsref->refupperindexpr = upperIndexpr;
|
|
|
|
sbsref->reflowerindexpr = lowerIndexpr;
|
|
|
|
sbsref->refexpr = (Expr *) containerBase;
|
|
|
|
sbsref->refassgnexpr = (Expr *) assignFrom;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2019-02-01 16:50:32 +01:00
|
|
|
return sbsref;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
1999-11-01 06:06:21 +01:00
|
|
|
* make_const
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
1999-11-01 06:06:21 +01:00
|
|
|
* Convert a Value node (as returned by the grammar) to a Const node
|
2000-02-24 02:59:17 +01:00
|
|
|
* of the "natural" type for the constant. Note that this routine is
|
|
|
|
* only used when there is no explicit cast for the constant, so we
|
|
|
|
* have to guess what type is wanted.
|
|
|
|
*
|
|
|
|
* For string literals we produce a constant of type UNKNOWN ---- whose
|
2005-05-30 03:20:50 +02:00
|
|
|
* representation is the same as cstring, but it indicates to later type
|
|
|
|
* resolution that we're not sure yet what type it should be considered.
|
2000-02-24 02:59:17 +01:00
|
|
|
* Explicit "NULL" constants are also typed as UNKNOWN.
|
|
|
|
*
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
* For integers and floats we produce int4, int8, or numeric depending
|
2005-04-23 20:35:12 +02:00
|
|
|
* on the value of the number. XXX We should produce int2 as well,
|
|
|
|
* but additional cleanup is needed before we can do that; there are
|
|
|
|
* too many examples that fail if we try.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
1998-02-26 05:46:47 +01:00
|
|
|
Const *
|
2008-09-01 22:42:46 +02:00
|
|
|
make_const(ParseState *pstate, Value *value, int location)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2008-09-01 22:42:46 +02:00
|
|
|
Const *con;
|
1997-09-08 04:41:22 +02:00
|
|
|
Datum val;
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
int64 val64;
|
1999-11-01 06:06:21 +01:00
|
|
|
Oid typeid;
|
|
|
|
int typelen;
|
|
|
|
bool typebyval;
|
2008-09-01 22:42:46 +02:00
|
|
|
ParseCallbackState pcbstate;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
switch (nodeTag(value))
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_Integer:
|
|
|
|
val = Int32GetDatum(intVal(value));
|
1999-11-01 06:06:21 +01:00
|
|
|
|
|
|
|
typeid = INT4OID;
|
|
|
|
typelen = sizeof(int32);
|
|
|
|
typebyval = true;
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_Float:
|
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
|
|
|
/* could be an oversize integer as well as a float ... */
|
|
|
|
if (scanint8(strVal(value), true, &val64))
|
1997-09-08 04:41:22 +02:00
|
|
|
{
|
2005-04-23 20:35:12 +02:00
|
|
|
/*
|
|
|
|
* It might actually fit in int32. Probably only INT_MIN can
|
|
|
|
* occur, but we'll code the test generally just to be sure.
|
|
|
|
*/
|
2005-10-15 04:49:52 +02:00
|
|
|
int32 val32 = (int32) val64;
|
2005-04-23 20:35:12 +02:00
|
|
|
|
|
|
|
if (val64 == (int64) val32)
|
|
|
|
{
|
|
|
|
val = Int32GetDatum(val32);
|
|
|
|
|
|
|
|
typeid = INT4OID;
|
|
|
|
typelen = sizeof(int32);
|
|
|
|
typebyval = true;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
val = Int64GetDatum(val64);
|
|
|
|
|
|
|
|
typeid = INT8OID;
|
|
|
|
typelen = sizeof(int64);
|
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
2017-06-21 21:18:54 +02:00
|
|
|
typebyval = FLOAT8PASSBYVAL; /* int8 and float8 alike */
|
2005-04-23 20:35:12 +02:00
|
|
|
}
|
1997-09-08 04:41:22 +02:00
|
|
|
}
|
2000-02-24 02:59:17 +01:00
|
|
|
else
|
|
|
|
{
|
2008-09-01 22:42:46 +02:00
|
|
|
/* arrange to report location if numeric_in() fails */
|
|
|
|
setup_parser_errposition_callback(&pcbstate, pstate, location);
|
2000-06-13 09:35:40 +02:00
|
|
|
val = DirectFunctionCall3(numeric_in,
|
|
|
|
CStringGetDatum(strVal(value)),
|
|
|
|
ObjectIdGetDatum(InvalidOid),
|
|
|
|
Int32GetDatum(-1));
|
2008-09-01 22:42:46 +02:00
|
|
|
cancel_parser_errposition_callback(&pcbstate);
|
2000-02-24 02:59:17 +01:00
|
|
|
|
|
|
|
typeid = NUMERICOID;
|
|
|
|
typelen = -1; /* variable len */
|
|
|
|
typebyval = false;
|
|
|
|
}
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_String:
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2005-05-30 03:20:50 +02:00
|
|
|
/*
|
|
|
|
* We assume here that UNKNOWN's internal representation is the
|
|
|
|
* same as CSTRING
|
|
|
|
*/
|
|
|
|
val = CStringGetDatum(strVal(value));
|
1999-11-01 06:06:21 +01:00
|
|
|
|
2001-10-28 07:26:15 +01:00
|
|
|
typeid = UNKNOWNOID; /* will be coerced later */
|
2005-10-15 04:49:52 +02:00
|
|
|
typelen = -2; /* cstring-style varwidth type */
|
1999-11-01 06:06:21 +01:00
|
|
|
typebyval = false;
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-10-31 11:22:13 +01:00
|
|
|
case T_BitString:
|
2008-09-01 22:42:46 +02:00
|
|
|
/* arrange to report location if bit_in() fails */
|
|
|
|
setup_parser_errposition_callback(&pcbstate, pstate, location);
|
2001-05-22 18:37:17 +02:00
|
|
|
val = DirectFunctionCall3(bit_in,
|
2000-10-31 11:22:13 +01:00
|
|
|
CStringGetDatum(strVal(value)),
|
|
|
|
ObjectIdGetDatum(InvalidOid),
|
|
|
|
Int32GetDatum(-1));
|
2008-09-01 22:42:46 +02:00
|
|
|
cancel_parser_errposition_callback(&pcbstate);
|
2001-05-22 18:37:17 +02:00
|
|
|
typeid = BITOID;
|
2000-10-31 11:22:13 +01:00
|
|
|
typelen = -1;
|
|
|
|
typebyval = false;
|
|
|
|
break;
|
|
|
|
|
2000-02-24 02:59:17 +01:00
|
|
|
case T_Null:
|
1999-11-01 06:06:21 +01:00
|
|
|
/* return a null const */
|
1999-12-24 07:43:34 +01:00
|
|
|
con = makeConst(UNKNOWNOID,
|
2007-03-17 01:11:05 +01:00
|
|
|
-1,
|
2011-03-26 01:10:42 +01:00
|
|
|
InvalidOid,
|
2005-05-30 03:20:50 +02:00
|
|
|
-2,
|
2003-07-19 22:20:53 +02:00
|
|
|
(Datum) 0,
|
1999-12-24 07:43:34 +01:00
|
|
|
true,
|
|
|
|
false);
|
2008-08-29 01:09:48 +02:00
|
|
|
con->location = location;
|
1999-11-01 06:06:21 +01:00
|
|
|
return con;
|
2003-07-19 22:20:53 +02:00
|
|
|
|
|
|
|
default:
|
|
|
|
elog(ERROR, "unrecognized node type: %d", (int) nodeTag(value));
|
|
|
|
return NULL; /* keep compiler quiet */
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1999-11-01 06:06:21 +01:00
|
|
|
con = makeConst(typeid,
|
2007-03-17 01:11:05 +01:00
|
|
|
-1, /* typmod -1 is OK for all cases */
|
2011-04-10 17:42:00 +02:00
|
|
|
InvalidOid, /* all cases are uncollatable types */
|
1999-11-01 06:06:21 +01:00
|
|
|
typelen,
|
1997-09-07 07:04:48 +02:00
|
|
|
val,
|
|
|
|
false,
|
2002-11-25 22:29:42 +01:00
|
|
|
typebyval);
|
2008-08-29 01:09:48 +02:00
|
|
|
con->location = location;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return con;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|