Re: [PERFORM] typoed column name, but postgres didn't grump
От | Merlin Moncure |
---|---|
Тема | Re: [PERFORM] typoed column name, but postgres didn't grump |
Дата | |
Msg-id | AANLkTikymqi_chTOgpUzmFfA_hCbEQLDwhaA7No_1hgq@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 Thu, Nov 4, 2010 at 12:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> Merlin Moncure <mmoncure@gmail.com> wrote: >>> 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)); > >> It already does: > > I think Merlin probably meant to write "select x((1,2))", but that > doesn't work out-of-the-box either. =A0What would be affected is > something like Actually I didn't -- I left out that there was a function f taking x. I misunderstood your assertion above: "The notation t(x) will be taken to mean x::t if there's no function t() taking x's type, but there is a cast from x's type to t". I thought you meant that it would no longer implicitly cast where it used to for record types, rather than the expression rewrite it was doing (it just clicked). Anyways, no objection to the change, or even the backpatch if you'd like to do that. FWIW. If we ever have an IOCCCish contest for postgresql variant of SQL, there are some real gems in this thread :-). merlin
В списке pgsql-bugs по дате отправления: