Re: Making view dump/restore safe at the column-alias level
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <stark@mit.edu>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-12-31T15:27:10Z
Lists: pgsql-hackers
Greg Stark <stark@mit.edu> writes: > I do wonder whether the SQL standard will do something obtuse enough > that that's the only option for a large swathe of queries. Or is that > the case already? The query syntax you're using here, is it standard > SQL? Is it widely supported? Yeah, it's standard --- there's nothing here that wasn't in SQL92. (Although I notice that SQL still hasn't got any ALTER TABLE RENAME command, much less a column rename command. I wonder whether the committee is aware of these difficulties and has shied away from adding RENAME because of them?) As for widely supported, I can't imagine that the big boys don't have this, although a quick test shows that mysql only has table aliases not column aliases, ie you can do "FROM t1 AS t1x" but not "FROM t1 AS t1x(y)". Still, if that's a consideration, inventing our own syntax would be even further away from the goal. Also, the patch goes to some lengths to not print column aliases unnecessarily --- in fact, there are cases where the old code would print column aliases but the patch will not. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Improve ruleutils.c's heuristics for dealing with rangetable aliases.
- 11e131854f82 9.3.0 cited