From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mark Dilger <hornschnorter@gmail.com>
Cc: Regina Obe <lr@pcorp.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
Date: Mon, 12 Jun 2017 17:32:28 -0700
Message-ID: <20170613003228.2o7plhmcynzaubwz@alap3.anarazel.de> (raw)
In-Reply-To: <5259.1497044025@sss.pgh.pa.us>
References: <4125B63A-886A-442D-9932-34F0D4F76D41@gmail.com>
<20170604193521.ha6d5kpkdswmissm@alap3.anarazel.de>
<63850C96-9570-4969-8074-7033DA4C334F@gmail.com>
<20170604211942.aiavcbagsho5owcz@alap3.anarazel.de>
<FB5BA655-95A0-4EC5-900D-2582D3E98A74@gmail.com>
<13450.1496861842@sss.pgh.pa.us>
<25987.1496977553@sss.pgh.pa.us>
<20170609032619.crv3skkf7tvzj63j@alap3.anarazel.de>
<27103.1496979469@sss.pgh.pa.us>
<5259.1497044025@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2017-06-09 17:33:45 -0400, Tom Lane wrote:
> diff --git a/src/backend/catalog/information_schema.sql b/src/backend/catalog/information_schema.sql
> index cbcd6cf..98bcfa0 100644
> --- a/src/backend/catalog/information_schema.sql
> +++ b/src/backend/catalog/information_schema.sql
> @@ -2936,12 +2936,14 @@ CREATE VIEW user_mapping_options AS
> SELECT authorization_identifier,
> foreign_server_catalog,
> foreign_server_name,
> - CAST((pg_options_to_table(um.umoptions)).option_name AS sql_identifier) AS option_name,
> + CAST(opts.option_name AS sql_identifier) AS option_name,
> CAST(CASE WHEN (umuser <> 0 AND authorization_identifier = current_user)
> OR (umuser = 0 AND pg_has_role(srvowner, 'USAGE'))
> - OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user) THEN (pg_options_to_table(um.umoptions)).option_value
> + OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
> + THEN opts.option_value
> ELSE NULL END AS character_data) AS option_value
> - FROM _pg_user_mappings um;
> + FROM _pg_user_mappings um,
> + pg_options_to_table(um.umoptions) opts;
This really is a lot better...
> GRANT SELECT ON user_mapping_options TO PUBLIC;
>
> diff --git a/src/backend/executor/functions.c b/sindex a35ba32..89aea2f 100644
> --- a/src/backend/executor/functions.c
> +++ b/src/backend/executor/functions.c
> @@ -388,6 +388,7 @@ sql_fn_post_column_ref(ParseState *pstat
> param = ParseFuncOrColumn(pstate,
> list_make1(subfield),
> list_make1(param),
> + pstate->p_last_srf,
> NULL,
> cref->location);
> }
> diff --git a/src/backend/parser/parse_aindex efe1c37..5241fd2 100644
> --- a/src/backend/parser/parse_agg.c
> +++ b/src/backend/parser/parse_agg.c
> @@ -705,6 +705,13 @@ check_agg_arguments_walker(Node *node,
> }
> /* Continue and descend into subtree */
> }
> + /* We can throw error on sight for a set-returning function */
> + if ((IsA(node, FuncExpr) &&((FuncExpr *) node)->funcretset) ||
> + (IsA(node, OpExpr) &&((OpExpr *) node)->opretset))
> + ereport(ERROR,
> + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> + errmsg("aggregate function calls cannot contain set-returning function calls"),
> + parser_errposition(context->pstate, exprLocation(node))));
Possibly too hard to be precise enough in a hint, but a number of these
could benefit from one suggesting moving things into FROM, using
LATERAL.
I'm kinda positively surprised at how non-invasive this turned out, I'd
afraid there'd be a lot more verbosity to it. I think the improved
error messages (message & location), are quite worthwhile an their own.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, tgl@sss.pgh.pa.us, hornschnorter@gmail.com, lr@pcorp.us
Subject: Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
In-Reply-To: <20170613003228.2o7plhmcynzaubwz@alap3.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox