tracking inherited columns (was: patch for check constraints using multiple inheritance)
in [PgSql]
|
Prev: Patch to show individual statement latencies in pgbench output
Next: [HACKERS] Two problems when using Postgresql8.3.7, Please help me!
From: Tom Lane on 5 Aug 2010 09:59 Robert Haas <robertmhaas(a)gmail.com> writes: > Yeb Havinga <yebhavinga(a)gmail.com> writes: >> The root cause seems to center around multiple inheritance of the same >> column without a common ancestor. Another way to approach the problem, is to >> prevent the user to create a setup, i.e. when adding a column to B that >> already exists in A, or when adding a inheritance relation A-C or B-c, if A >> and B share column names. He could then get a hint he should add a common >> ancestor with that column. This preemptively prevents problems with renames >> and other changes. > It also breaks compatibility with previous releases for no particular > reason. Well, if it were only a hint, and thus didn't actually "prevent" anything, then it wouldn't be breaking compatibility. But I don't like the idea much either. It would be extremely expensive, if not impossible, to determine whether all parents having the similarly-named column got it from the same common ancestor. (In particular, if the user had previously ignored the hint, you could have situations where there isn't a unique ancestor that the column can be traced to; then what do you do?) I think we'd be putting huge amounts of effort into a case that no more than one or two people would ever hit. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 5 Aug 2010 10:10 On Thu, Aug 5, 2010 at 9:59 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Well, if it were only a hint, and thus didn't actually "prevent" > anything, then it wouldn't be breaking compatibility. �But I don't > like the idea much either. �It would be extremely expensive, if not > impossible, to determine whether all parents having the similarly-named > column got it from the same common ancestor. �(In particular, if the > user had previously ignored the hint, you could have situations where > there isn't a unique ancestor that the column can be traced to; then > what do you do?) > > I think we'd be putting huge amounts of effort into a case that no more > than one or two people would ever hit. I don't agree that it would be a huge amount of effort, but I do agree that only a very small number of people will ever hit it, and that it just doesn't seem worth it. We have bigger fish to fry. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 5 Aug 2010 07:26
On Thu, Aug 5, 2010 at 6:15 AM, Yeb Havinga <yebhavinga(a)gmail.com> wrote: > Tom Lane wrote: >> >> Yeb Havinga <yebhavinga(a)gmail.com> writes: >> >>> >>> A.a_column � �B.a_column >>> � � | � � � / >>> � � v � � �v >>> � �C.a_column >>> � �C inherits from A and B. >>> >> >> Well, if A and B inherited the column from a common ancestor, he can >> easily do that. �If not, maybe he should have thought harder before he >> started. �I do NOT agree that issuing a rename against C is a sane way >> of dealing with this. >> > > Ok, I understand the intuition behind not wanting this kind of update. > > The root cause seems to center around multiple inheritance of the same > column without a common ancestor. Another way to approach the problem, is to > prevent the user to create a setup, i.e. when adding a column to B that > already exists in A, or when adding a inheritance relation A-C or B-c, if A > and B share column names. He could then get a hint he should add a common > ancestor with that column. This preemptively prevents problems with renames > and other changes. It also breaks compatibility with previous releases for no particular reason. These cases are all marginal enough that it doesn't really make sense to change historical behavior; I think we should confine our efforts to fixing the bugs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |