Re: ALTER TABLE INHERIT vs collations
От | Thom Brown |
---|---|
Тема | Re: ALTER TABLE INHERIT vs collations |
Дата | |
Msg-id | BANLkTinrcLETqtKu6_zWtz-t3qyt9LjfBQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE INHERIT vs collations (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 17 April 2011 00:40, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> On 16 April 2011 23:23, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Does anyone think it's not a bug that ALTER TABLE lets this through? >>> If so, what do you think the querying semantics ought to be? > >> An argument to not treat it as a bug might be to suggest that the >> child table's column could inherit the parent table's column collation >> when the query targets the parent, but revert to its own otherwise. > > That seems to me to be about on par with arguing that inheritance > shouldn't demand column type matching, but should coerce child columns > on-the-fly to their parent's type. Even if you don't think that's > horrid from a theoretical standpoint, there's a good practical reason > not to allow it: if it acts that way, then indexes on the child column > will silently not be usable for many kinds of query against the parent. > People will be tearing their hair out looking for the cause of their > performance problems ... and, no doubt, filing bugs against the planner > ... when throwing an error would have helped them catch the mismatch. > > I think there needs to be a pretty darn compelling use-case for such > mismatches before we should allow them. And I don't see one. Conceded. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: