Marko Tiikkaja-4 wrote > On 2014-09-05 22:38, Oskari Saarenmaa wrote: >> I wrote the attached patch to optionally emit warnings when column or >> table >> aliases are used without the AS keyword after errors caused by typos in >> statements turning unintended things into aliases came up twice this >> week. >> First in a discussion with a colleague who was surprised by a 1 row >> result >> for the query 'SELECT COUNT(*) files' and again in the "pl/pgsql 2" >> thread >> as plpgsql currently doesn't throw an error if there are more result >> columns >> than output columns (SELECT a b INTO f1, f2). >> >> The patch is still missing documentation and it needs another patch to >> modify all the statements in psql & co to use AS so you can use things >> like >> \d and tab-completion without triggering the warnings. I can implement >> those changes if others think this patch makes sense. > > 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. 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. 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. Stuff like correlated subqueries without alias use could be part of that (to avoid typos that result in constant true) and also duplicate column names floating to the top-most select-list, or failure to use an alias on a function call result. There are probably others though I'm stretching to even find these... 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?) David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/PATCH-parser-optionally-warn-about-missing-AS-for-column-and-table-aliases-tp5817971p5817980.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
