Thread: Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Alvaro Herrera wrote: >> Here's a first attempt at fixing this. It makes the test pass, but I >> have the feeling that more complex ones might need more work. > Here's another one with three main differences: Hmm. The bespoke code for constructing the attno map bothers me; surely there is existing code that does that? If not, it'd still make more sense to factor it out, I think, because there will be other needs for it in future. Otherwise, this seems sound in terms of fixing the observed problem, but what are the implications for event triggers exactly? Does a trigger see only the original expression, or only the modified expression, or ??? regards, tom lane
Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. haswrong type
From
Alvaro Herrera
Date:
Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > Alvaro Herrera wrote: > >> Here's a first attempt at fixing this. It makes the test pass, but I > >> have the feeling that more complex ones might need more work. > > > Here's another one with three main differences: > > Hmm. The bespoke code for constructing the attno map bothers me; > surely there is existing code that does that? If not, it'd still > make more sense to factor it out, I think, because there will be > other needs for it in future. There isn't any that I could find -- all the existing callers of map_variable_attnos build their map in other ways (while walking an attribute array at construction time). So I did as you suggest, 'cause it sounds like a good idea, but the problem crops up of where to put the new function. The obvious candidate is rewriteManip.c next to map_variable_attnos itself, but the include creep is a bit bothersome -- maybe it indicates that the new function should be elsewhere. But then, the whole of rewriteManip seems not terribly well delimited to the rewriter itself but just an assorted collection of walkers, mutators, and similar utilities used by code all over the place, so perhaps this is not a problem. I also modified the algorithm to use the relcache instead of walking the child's attribute list for each parent attribute (that was silly). Here's the new version. > Otherwise, this seems sound in terms of fixing the observed problem, > but what are the implications for event triggers exactly? Does a > trigger see only the original expression, or only the modified expression, > or ??? My rationale when writing the event trigger code was that each command would only be published once, for the parent table, not recursively for each child. So only the original expression should be seen. I have not yet verified the actual behavior in the differing attnums case. One problem at a time ... -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers