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
|
|
|
*
|
2015-01-06 17:43:47 +01:00
|
|
|
* Portions Copyright (c) 1996-2015, 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"
|
|
|
|
|
2007-06-24 00:12:52 +02:00
|
|
|
#include "access/heapam.h"
|
2012-08-30 22:15:44 +02:00
|
|
|
#include "access/htup_details.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"
|
2002-03-12 01:52:10 +01:00
|
|
|
#include "parser/parsetree.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"
|
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
|
|
|
|
1997-11-26 04:43:18 +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;
|
|
|
|
|
|
|
|
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;
|
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)
|
|
|
|
heap_close(pstate->p_target_relation, NoLock);
|
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1999-11-01 06:06:21 +01:00
|
|
|
/*
|
|
|
|
* make_var
|
2000-09-12 23:07:18 +02:00
|
|
|
* Build a Var node for an attribute identified by RTE and attrno
|
1999-11-01 06:06:21 +01:00
|
|
|
*/
|
1998-02-26 05:46:47 +01:00
|
|
|
Var *
|
2008-08-29 01:09:48 +02:00
|
|
|
make_var(ParseState *pstate, RangeTblEntry *rte, int attrno, int location)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2008-08-29 01:09:48 +02:00
|
|
|
Var *result;
|
1997-09-08 04:41:22 +02:00
|
|
|
int vnum,
|
2000-09-12 23:07:18 +02:00
|
|
|
sublevels_up;
|
2002-03-12 01:52:10 +01:00
|
|
|
Oid vartypeid;
|
|
|
|
int32 type_mod;
|
2011-02-08 22:04:18 +01:00
|
|
|
Oid varcollid;
|
2000-09-12 23:07:18 +02:00
|
|
|
|
|
|
|
vnum = RTERangeTablePosn(pstate, rte, &sublevels_up);
|
2011-02-08 22:04:18 +01:00
|
|
|
get_rte_attribute_type(rte, attrno, &vartypeid, &type_mod, &varcollid);
|
|
|
|
result = makeVar(vnum, attrno, vartypeid, type_mod, varcollid, sublevels_up);
|
2008-08-29 01:09:48 +02:00
|
|
|
result->location = location;
|
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
/*
|
|
|
|
* transformArrayType()
|
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
|
|
|
* Identify the types involved in a subscripting operation
|
|
|
|
*
|
|
|
|
* On entry, arrayType/arrayTypmod 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 array type and typmod, and the
|
|
|
|
* array's element type is returned. An error is thrown if the input isn't
|
|
|
|
* an array type.
|
2004-06-09 21:08:20 +02:00
|
|
|
*/
|
|
|
|
Oid
|
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
|
|
|
transformArrayType(Oid *arrayType, int32 *arrayTypmod)
|
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
|
|
|
Oid origArrayType = *arrayType;
|
2004-06-09 21:08:20 +02:00
|
|
|
Oid elementType;
|
|
|
|
HeapTuple type_tuple_array;
|
|
|
|
Form_pg_type type_struct_array;
|
|
|
|
|
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
|
|
|
|
* typmod to be applied to the base type. Subscripting a domain is an
|
|
|
|
* operation that necessarily works on the base array type, not the domain
|
2014-05-06 18:12:18 +02:00
|
|
|
* itself. (Note that we provide no method whereby the creator of a
|
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
|
|
|
* domain over an array type could hide its ability to be subscripted.)
|
|
|
|
*/
|
|
|
|
*arrayType = getBaseTypeAndTypmod(*arrayType, arrayTypmod);
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
if (*arrayType == INT2VECTOROID)
|
|
|
|
*arrayType = INT2ARRAYOID;
|
|
|
|
else if (*arrayType == OIDVECTOROID)
|
|
|
|
*arrayType = OIDARRAYOID;
|
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
/* Get the type tuple for the array */
|
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
|
|
|
type_tuple_array = SearchSysCache1(TYPEOID, ObjectIdGetDatum(*arrayType));
|
2004-06-09 21:08:20 +02:00
|
|
|
if (!HeapTupleIsValid(type_tuple_array))
|
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
|
|
|
elog(ERROR, "cache lookup failed for type %u", *arrayType);
|
2004-06-09 21:08:20 +02:00
|
|
|
type_struct_array = (Form_pg_type) GETSTRUCT(type_tuple_array);
|
|
|
|
|
|
|
|
/* needn't check typisdefined since this will fail anyway */
|
|
|
|
|
|
|
|
elementType = type_struct_array->typelem;
|
|
|
|
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",
|
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
|
|
|
format_type_be(origArrayType))));
|
2004-06-09 21:08:20 +02:00
|
|
|
|
|
|
|
ReleaseSysCache(type_tuple_array);
|
|
|
|
|
|
|
|
return elementType;
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
1999-07-19 02:26:20 +02:00
|
|
|
* transformArraySubscripts()
|
|
|
|
* Transform array subscripting. This is used for both
|
|
|
|
* array fetch and array assignment.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1999-07-19 02:26:20 +02:00
|
|
|
* In an array fetch, we are given a source array value and we produce an
|
|
|
|
* expression that represents the result of extracting a single array element
|
|
|
|
* or an array slice.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1999-07-19 02:26:20 +02:00
|
|
|
* In an array assignment, we are given a destination array value plus a
|
|
|
|
* source value that is to be assigned to a single element or a slice of
|
2014-05-06 18:12:18 +02:00
|
|
|
* that array. We produce an expression that represents the new array value
|
1999-07-19 02:26:20 +02:00
|
|
|
* with the source data inserted into the right part of the array.
|
|
|
|
*
|
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
|
|
|
* For both cases, if the source array is of a domain-over-array type,
|
|
|
|
* 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
|
|
|
*
|
1999-07-19 02:26:20 +02:00
|
|
|
* pstate Parse state
|
|
|
|
* arrayBase Already-transformed expression for the array as a whole
|
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
|
|
|
* arrayType OID of array's datatype (should match type of arrayBase,
|
|
|
|
* or be the base type of arrayBase's domain type)
|
2004-06-09 21:08:20 +02:00
|
|
|
* elementType OID of array's element type (fetch with transformArrayType,
|
|
|
|
* or pass InvalidOid to do it 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
|
|
|
* arrayTypMod typmod for the array (which is also typmod for the elements)
|
1999-07-19 02:26:20 +02:00
|
|
|
* indirection Untransformed list of subscripts (must not be NIL)
|
|
|
|
* assignFrom NULL for array fetch, else transformed expression for source.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2001-10-25 07:50:21 +02:00
|
|
|
ArrayRef *
|
1999-07-19 02:26:20 +02:00
|
|
|
transformArraySubscripts(ParseState *pstate,
|
|
|
|
Node *arrayBase,
|
2001-02-14 22:35:07 +01:00
|
|
|
Oid arrayType,
|
2004-06-09 21:08:20 +02:00
|
|
|
Oid elementType,
|
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
|
|
|
int32 arrayTypMod,
|
1999-07-19 02:26:20 +02:00
|
|
|
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;
|
1999-07-19 02:26:20 +02:00
|
|
|
ArrayRef *aref;
|
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
|
2011-04-10 17:42:00 +02:00
|
|
|
* that if the caller did do so, arrayType/arrayTypMod must be as modified
|
|
|
|
* by transformArrayType, 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))
|
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
|
|
|
elementType = transformArrayType(&arrayType, &arrayTypMod);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-07-19 02:26:20 +02:00
|
|
|
/*
|
|
|
|
* A list containing only single subscripts refers to a single array
|
2005-10-15 04:49:52 +02:00
|
|
|
* element. If any of the items are double subscripts (lower:upper), then
|
|
|
|
* the subscript expression means an array slice operation. In this case,
|
|
|
|
* we supply a default lower bound of 1 for any items that contain only a
|
|
|
|
* single subscript. We have to prescan the indirection list to see if
|
|
|
|
* there are any double subscripts.
|
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
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
if (ai->lidx != NULL)
|
|
|
|
{
|
|
|
|
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
|
|
|
{
|
|
|
|
A_Indices *ai = (A_Indices *) lfirst(idx);
|
|
|
|
Node *subexpr;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2004-06-09 21:08:20 +02:00
|
|
|
Assert(IsA(ai, A_Indices));
|
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"),
|
2009-06-11 16:49:15 +02:00
|
|
|
parser_errposition(pstate, exprLocation(ai->lidx))));
|
1999-07-19 02:26:20 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* 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,
|
2002-11-25 22:29:42 +01:00
|
|
|
true); /* pass by value */
|
1999-07-19 02:26:20 +02:00
|
|
|
}
|
|
|
|
lowerIndexpr = lappend(lowerIndexpr, subexpr);
|
|
|
|
}
|
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->uidx, 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,
|
|
|
|
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"),
|
|
|
|
parser_errposition(pstate, exprLocation(ai->uidx))));
|
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);
|
2001-02-14 22:35:07 +01:00
|
|
|
Oid typeneeded = isSlice ? arrayType : 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,
|
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
|
|
|
typeneeded, arrayTypMod,
|
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)),
|
2009-06-11 16:49:15 +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
|
|
|
/*
|
|
|
|
* Ready to build the ArrayRef node.
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
aref = makeNode(ArrayRef);
|
2003-04-09 01:20:04 +02:00
|
|
|
aref->refarraytype = arrayType;
|
|
|
|
aref->refelemtype = elementType;
|
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
|
|
|
aref->reftypmod = arrayTypMod;
|
2011-03-20 01:29:08 +01:00
|
|
|
/* refcollid will be set by parse_collate.c */
|
1997-09-07 07:04:48 +02:00
|
|
|
aref->refupperindexpr = upperIndexpr;
|
|
|
|
aref->reflowerindexpr = lowerIndexpr;
|
2002-12-12 16:49:42 +01:00
|
|
|
aref->refexpr = (Expr *) arrayBase;
|
|
|
|
aref->refassgnexpr = (Expr *) assignFrom;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
return aref;
|
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);
|
2009-06-11 16:49:15 +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
|
|
|
}
|