I'd omitted this from the grammar in commit
c9d529848, figuring that
it wasn't worth supporting. However we already have one complaint,
so it seems that judgment was wrong. It doesn't require a huge
amount of code, so add it back. (I'm still drawing the line at
UNION/INTERSECT/EXCEPT though: those'd require an unreasonable
amount of grammar refactoring, and the single-result-row restriction
makes them near useless anyway.)
Also rethink the documentation: this behavior is a property of
all pl/pgsql expressions, not just assignments.
Discussion: https://postgr.es/m/
20210122134106.
e94c5cd7@mail.verfriemelt.org
they are useful to know when trying to diagnose a problem.
More information appears in <xref linkend="plpgsql-plan-caching"/>.
</para>
+
+ <para>
+ Since an <replaceable>expression</replaceable> is converted to a
+ <literal>SELECT</literal> command, it can contain the same clauses
+ that an ordinary <literal>SELECT</literal> would, except that it
+ cannot include a top-level <literal>UNION</literal>,
+ <literal>INTERSECT</literal>, or <literal>EXCEPT</literal> clause.
+ Thus for example one could test whether a table is non-empty with
+<programlisting>
+IF count(*) > 0 FROM my_table THEN ...
+</programlisting>
+ since the <replaceable>expression</replaceable>
+ between <literal>IF</literal> and <literal>THEN</literal> is parsed as
+ though it were <literal>SELECT count(*) > 0 FROM my_table</literal>.
+ The <literal>SELECT</literal> must produce a single column, and not
+ more than one row. (If it produces no rows, the result is taken as
+ NULL.)
+ </para>
</sect1>
<sect1 id="plpgsql-statements">
complex_array[n].realpart = 12.3;
</programlisting>
</para>
-
- <para>
- It's useful to know that what follows the assignment operator is
- essentially treated as a <literal>SELECT</literal> command; as long
- as it returns a single row and column, it will work. Thus for example
- one can write something like
-<programlisting>
-total_sales := sum(quantity) from sales;
-</programlisting>
- This provides an effect similar to the single-row <literal>SELECT
- ... INTO</literal> syntax described in
- <xref linkend="plpgsql-statements-sql-onerow"/>. However, that syntax
- is more portable.
- </para>
</sect2>
<sect2 id="plpgsql-statements-sql-noresult">
/*
* The rest mostly matches transformSelectStmt, except that we needn't
- * consider WITH or DISTINCT, and we build a targetlist our own way.
+ * consider WITH or INTO, and we build a targetlist our own way.
*/
qry->commandType = CMD_SELECT;
pstate->p_is_insert = false;
EXPR_KIND_GROUP_BY,
false /* allow SQL92 rules */ );
- /* No DISTINCT clause */
- Assert(!sstmt->distinctClause);
- qry->distinctClause = NIL;
- qry->hasDistinctOn = false;
+ if (sstmt->distinctClause == NIL)
+ {
+ qry->distinctClause = NIL;
+ qry->hasDistinctOn = false;
+ }
+ else if (linitial(sstmt->distinctClause) == NULL)
+ {
+ /* We had SELECT DISTINCT */
+ qry->distinctClause = transformDistinctClause(pstate,
+ &qry->targetList,
+ qry->sortClause,
+ false);
+ qry->hasDistinctOn = false;
+ }
+ else
+ {
+ /* We had SELECT DISTINCT ON */
+ qry->distinctClause = transformDistinctOnClause(pstate,
+ sstmt->distinctClause,
+ &qry->targetList,
+ qry->sortClause);
+ qry->hasDistinctOn = true;
+ }
/* transform LIMIT */
qry->limitOffset = transformLimitClause(pstate, sstmt->limitOffset,
OptTableElementList TableElementList OptInherit definition
OptTypedTableElementList TypedTableElementList
reloptions opt_reloptions
- OptWith distinct_clause opt_definition func_args func_args_list
+ OptWith opt_definition func_args func_args_list
func_args_with_defaults func_args_with_defaults_list
aggr_args aggr_args_list
func_as createfunc_opt_list alterfunc_opt_list
name_list role_list from_clause from_list opt_array_bounds
qualified_name_list any_name any_name_list type_name_list
any_operator expr_list attrs
+ distinct_clause opt_distinct_clause
target_list opt_target_list insert_column_list set_target_list
set_clause_list set_clause
def_list operator_def_list indirection opt_indirection
* As with select_no_parens, simple_select cannot have outer parentheses,
* but can have parenthesized subclauses.
*
+ * It might appear that we could fold the first two alternatives into one
+ * by using opt_distinct_clause. However, that causes a shift/reduce conflict
+ * against INSERT ... SELECT ... ON CONFLICT. We avoid the ambiguity by
+ * requiring SELECT DISTINCT [ON] to be followed by a non-empty target_list.
+ *
* Note that sort clauses cannot be included at this level --- SQL requires
* SELECT foo UNION SELECT bar ORDER BY baz
* to be parsed as
| /*EMPTY*/
;
+opt_distinct_clause:
+ distinct_clause { $$ = $1; }
+ | opt_all_clause { $$ = NIL; }
+ ;
+
opt_sort_clause:
- sort_clause { $$ = $1;}
+ sort_clause { $$ = $1; }
| /*EMPTY*/ { $$ = NIL; }
;
* Therefore the returned struct is a SelectStmt.
*****************************************************************************/
-PLpgSQL_Expr: opt_target_list
+PLpgSQL_Expr: opt_distinct_clause opt_target_list
from_clause where_clause
group_clause having_clause window_clause
opt_sort_clause opt_select_limit opt_for_locking_clause
{
SelectStmt *n = makeNode(SelectStmt);
- n->targetList = $1;
- n->fromClause = $2;
- n->whereClause = $3;
- n->groupClause = $4;
- n->havingClause = $5;
- n->windowClause = $6;
- n->sortClause = $7;
- if ($8)
+ n->distinctClause = $1;
+ n->targetList = $2;
+ n->fromClause = $3;
+ n->whereClause = $4;
+ n->groupClause = $5;
+ n->havingClause = $6;
+ n->windowClause = $7;
+ n->sortClause = $8;
+ if ($9)
{
- n->limitOffset = $8->limitOffset;
- n->limitCount = $8->limitCount;
+ n->limitOffset = $9->limitOffset;
+ n->limitCount = $9->limitCount;
if (!n->sortClause &&
- $8->limitOption == LIMIT_OPTION_WITH_TIES)
+ $9->limitOption == LIMIT_OPTION_WITH_TIES)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("WITH TIES cannot be specified without ORDER BY clause")));
- n->limitOption = $8->limitOption;
+ n->limitOption = $9->limitOption;
}
- n->lockingClause = $9;
+ n->lockingClause = $10;
$$ = (Node *) n;
}
;
projects / postgresql.git / commitdiff