On 2014-09-05 11:19 PM, David G Johnston wrote:
Marko Tiikkaja-4 wrote
I think this is only problematic for column aliases. I wouldn't want to
put these two to be put into the same category, as I always omit the AS
keyword for tables aliases (and will continue to do so), but never omit
it for column aliases.
I agree on being able to pick the behavior independently for select-list
items and the FROM clause items.
Using this to mitigate the pl/pgsql column mis-match issue seems like too
broad of a solution.
The PL/PgSQL column can be solved via other methods; see for example my
suggestion of "PL/PgSQL warning - num_into_expressions" in the current
commit fest (and the non-backwards-compatible solution of throwing a
run-time error I suggested). But some people run SQL queries from their
apps, and I've seen people make this mistake and get confused.
I probably couldn't mount a convincing defense of my opinion but at first
blush I'd say we should pass on this. Not with prejudice - looking at the
issue periodically has merit - but right now it seems to be mostly adding
clutter to the code without significant benefit.
Are you talking about this particular option, or the notion of parser
warnings in general? Because if we're going to add a handful of
warnings, I don't see why this couldn't be on that list.
Tangential - I'd rather see something like "EXPLAIN (STATIC)" that would
allow a user to quickly invoke a built-in static SQL analyzer on their query
and have it point this kind of thing out. Adding a catalog for STATIC
configurations in much the same way we have text search configurations would
allow extensions and users to define their own rulesets that could be
attached to their ROLE "GUC: default_static_analyzer_ruleset" and also
passed in as a modifier in the EXPLAIN invocation.
If you knew there's a good chance you might make a mistake, you could
probably avoid doing it in the first place. I make mistakes all the
time, would I then always execute two commands when I want to do
something? Having to run a special "check my query please" command
seems silly.
Anyway, the idea of using a GUC and evaluating every query that is written
(the added if statements), is not that appealing even if the impact of one
more check is likely to be insignificant (is it?)
I'm not sure how you would do this differently in the EXPLAIN (STATIC)
case. Those ifs have to be somewhere, and that's always a non-zero cost.
That being said, yes, performance costs of course have to be evaluated
carefully.
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
