Re: [PERFORM] typoed column name, but postgres didn't grump
От | Merlin Moncure |
---|---|
Тема | Re: [PERFORM] typoed column name, but postgres didn't grump |
Дата | |
Msg-id | AANLkTimdEYcskXpSdiMDyK6R40G66T9SdM7JDUTvY=4h@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] typoed column name, but postgres didn't grump (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PERFORM] typoed column name, but postgres didn't
grump
|
Список | pgsql-bugs |
On Fri, Oct 29, 2010 at 4:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> Robert Haas <robertmhaas@gmail.com> wrote: >>>> I think if I had to pick a proposal, I'd say we should disable #2 >>>> for the specific case of casting a composite type to something >>>> else. > >>> Well, then let's do that. =A0It's not the exact fix I'd pick, but >>> it's clearly better than nothing, so I'm willing to sign on to it >>> as a compromise position. > >> So, I'd rather scrap #2 entirely; but if that really would break >> much working code, +1 for ignoring it when it would cast a composite >> to something else. > > Well, assuming for the sake of argument that we have consensus on fixing > it like that, is this something we should just do in HEAD, or should we > back-patch into 8.4 and 9.0? =A0We'll be hearing about it nigh > indefinitely if we don't, but on the other hand this isn't the kind of > thing we like to change in released branches. Trying to understand real world cases that this would break...would the following now fail w/o explicit cast? create type x as (a int, b int); select f((1,2)); merlin
В списке pgsql-bugs по дате отправления: