[REVIEW] Generate column names for subquery expressions
От | Kyotaro HORIGUCHI |
---|---|
Тема | [REVIEW] Generate column names for subquery expressions |
Дата | |
Msg-id | 20110914.112651.19132478.horiguchi.kyotaro@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [PATCH] Generate column names for subquery expressions (Marti Raudsepp <marti@juffo.org>) |
Ответы |
Re: [REVIEW] Generate column names for subquery expressions
|
Список | pgsql-hackers |
This is a review for the patch `Generate column names for subquery expressions' (https://commitfest.postgresql.org/action/patch_view?id=632) Summary ==================== Patch format is in context diff format. This patch applies cleanly on HEAD and make check suceeded. It seems have no problem to apply. Documents is needed to modify. Purpose and function of this patch ==================== This patch intends to name a part of the columns in the outmost SELECT caluse currently left unnamed - seen as `?column?' - and fix `unnatural' naming - seen as `int4', `case'. This patch figures column name after T_SubLink parse nodes corresponding to EXISTS, ARRAY, and subquery in addition to currently processed parse node types. It seems reasonable that (ALL|ANY|ROWCOMPARE|CTE)_SUBLINK is left unnnamed. Patch application, regression test ==================== The patch applies cleanly onto HEAD. make check yiels no error. This patch adds no additional test case and it seems ok. The coding style in this patch seems according to the convention. Behavior changes ==================== The behavior of column naming changes as following. STATEMENT AFTER BEFORE ----------------------------------------------------- select (select 1 as foo) foo ?column? select (exists (select 1)) exists ?column? select (array (select 1 as x)) array ?column? select (select 1 as aaa)::int aaa int4 select case when true then 1 else (select 1 as foo) end; foo case Aboves are same as described. But the following expression returns somewhat confising outcome. > select case when true then (select 2 as bar) else (select 1 as foo) end; > foo > ----- > 2 > (1 row) But this patch is not to blame for the behavior. The following is seen for unpatched pg. > # create table foo (a int, b int, c int); > # insert into foo values (1, 100, -100), (0, 10, -10), (-1, 25, -25); > # select case when a < 0 then b else c end from foo; > c > ------ (snipped) > # select case a when -1 then c when 1 then a else b end from foo; > b > ----- (snipped) Nevertheless this behavior seems a bit unnatural, it is not the issue for this patch. Performance ==================== This patch adds no extra load such as loops, recursive calls or deep calls. Added code runs for exists(), array() and subquery appear in the column list of select clause. So I think this patch can put only negligible impact on performance. Gleaning ==================== This patch assumes node(subLinkType==EXPR_SUBLINK)->subselect is not null, and it seems that gram.y(c) says the assumption is correct. I think this patch needs no documentation, but it is needed to edit the changed behaviors quoted in document. Maybe only one change as far as I have seen. http://www.postgresql.org/docs/9.0/static/sql-expressions.html > 4.2.11 .. > SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%'); > ?column? > ------------------------------------------------------------- > {2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31} Sincerely, -- Kyotaro Horiguchi
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Kyotaro HORIGUCHIДата:
Сообщение: [v9.2] make_greater_string() does not return a string in some cases