On Wed, Mar 23, 2016 at 1:00 PM, Abhijit Menon-Sen <a...@2ndquadrant.com> wrote: > Now, the first part of this works fine. But with the second part, I get > a reduce/reduce conflict if I use any_name. Here's an excerpt from the > verbose bison output: > > State 2920 > > 1181 AlterObjectDependsStmt: ALTER TRIGGER name ON any_name DEPENDS . ON > EXTENSION name > > ON shift, and go to state 3506 > > > State 2921 > > 1165 RenameStmt: ALTER TRIGGER name ON qualified_name RENAME . TO name > > TO shift, and go to state 3507
Yeah, that ain't gonna work. If the existing ALTER TRIGGER production uses "name ON qualified_name", switching to "name ON any_name" for the new production is not going to work. You're going to have to make it "name ON qualified_name" and deal with the fallout of that some other way. > I could change ExecAlterObjectDependsStmt() to check if stmt->relation > is set, and if so, convert the RangeVar back to a List* in the right > format before passing it to get_object_address. That would work fine, > but it doesn't seem like a good solution. > > I could write some get_object_address_rv() wrapper that does essentially > the same conversion, but that's only slightly better. I might have a view on which of these alternatives is for the best at some point in time, but I do not have one now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
