Re: [PERFORM] typoed column name, but postgres didn't grump
От | Tom Lane |
---|---|
Тема | Re: [PERFORM] typoed column name, but postgres didn't grump |
Дата | |
Msg-id | 29497.1288984644@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
|
Список | pgsql-bugs |
I wrote: > Ah. No, that would still work after the change. The case that I'm > proposing to break is using function-ish notation to invoke a cast > from a composite type to some other type whose name you use as if it > were a function. Even there, if you've created such a cast following > the usual convention of naming the cast function after the target type, > it'll still act the same. It's just the built-in I/O-based casts that > will stop working this way (for lack of a matching underlying function). Here's a proposed patch, sans documentation as yet. regards, tom lane diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c index b50bce448728280f63c695a688c004bd15bf84cf..9bb100e0c1e83c63b554f65300c03afed563373a 100644 *** a/src/backend/parser/parse_func.c --- b/src/backend/parser/parse_func.c *************** func_get_detail(List *funcname, *** 985,992 **** * can't write "foo[] (something)" as a function call. In theory * someone might want to invoke it as "_foo (something)" but we have * never supported that historically, so we can insist that people ! * write it as a normal cast instead. Lack of historical support is ! * also the reason for not considering composite-type casts here. * * NB: it's important that this code does not exceed what coerce_type * can do, because the caller will try to apply coerce_type if we --- 985,997 ---- * can't write "foo[] (something)" as a function call. In theory * someone might want to invoke it as "_foo (something)" but we have * never supported that historically, so we can insist that people ! * write it as a normal cast instead. ! * ! * We also reject the specific case of COERCEVIAIO for a composite ! * source type and a string-category target type. This is a case that ! * find_coercion_pathway() allows by default, but experience has shown ! * that it's too commonly invoked by mistake. So, again, insist that ! * people use cast syntax if they want to do that. * * NB: it's important that this code does not exceed what coerce_type * can do, because the caller will try to apply coerce_type if we *************** func_get_detail(List *funcname, *** 1017,1024 **** cpathtype = find_coercion_pathway(targetType, sourceType, COERCION_EXPLICIT, &cfuncid); ! iscoercion = (cpathtype == COERCION_PATH_RELABELTYPE || ! cpathtype == COERCION_PATH_COERCEVIAIO); } if (iscoercion) --- 1022,1044 ---- cpathtype = find_coercion_pathway(targetType, sourceType, COERCION_EXPLICIT, &cfuncid); ! switch (cpathtype) ! { ! case COERCION_PATH_RELABELTYPE: ! iscoercion = true; ! break; ! case COERCION_PATH_COERCEVIAIO: ! if ((sourceType == RECORDOID || ! ISCOMPLEX(sourceType)) && ! TypeCategory(targetType) == TYPCATEGORY_STRING) ! iscoercion = false; ! else ! iscoercion = true; ! break; ! default: ! iscoercion = false; ! break; ! } } if (iscoercion)
В списке pgsql-bugs по дате отправления:
Предыдущее
От: "Henry C."Дата:
Сообщение: Re: BUG #5736: 9.0.1 segmentation fault (sig11) during long-lived update
Следующее
От: "Kevin Grittner"Дата:
Сообщение: Re: [PERFORM] typoed column name, but postgres didn't grump