Re: ruleutils vs. empty targetlists

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: ruleutils vs. empty targetlists
Дата
Msg-id CAEZATCVU=7ERtVMTL5ThBVYiWUyYHRNMfpgYrz=YJ8jSfBCfcA@mail.gmail.com
обсуждение исходный текст
Ответ на ruleutils vs. empty targetlists  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ruleutils vs. empty targetlists
Список pgsql-hackers
On 3 December 2013 23:37, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thinking some more about bug #8648, it occurred to me that ruleutils.c
> isn't exactly prepared for the case either:
>
> regression=# create table nocols();
> CREATE TABLE
> regression=# create view vv1 as select exists (select * from nocols);
> CREATE VIEW
> regression=# \d+ vv1
>                   View "public.vv1"
>  Column |  Type   | Modifiers | Storage | Description
> --------+---------+-----------+---------+-------------
>  exists | boolean |           | plain   |
> View definition:
>  SELECT (EXISTS ( SELECT
>            FROM nocols)) AS "exists";
>
> which of course is illegal syntax.  I thought at first that this could be
> fixed trivially by emitting "*" if get_target_list found no columns.
> However, that doesn't quite work; consider
>
> create view vv2 as select exists (select nocols.* from nocols, somecols);
>
> If we regurgitate this as "exists (select * from nocols, somecols)", it
> wouldn't mean the same thing.
>
> But on the third hand, at least in the context of an EXISTS() subquery,
> it doesn't really matter because the tlist is irrelevant, at least as long
> as it only contains Vars.  So you could argue that emitting "*" is plenty
> good enough even in the above example.  I'm not certain that that applies
> everywhere that a tlist could appear, though.
>
> I experimented with code that would attempt to regurgitate "nocols.*"
> in the above example; see attached draft patch.  I don't like this patch
> much: it's ugly, it'd be a pain to backport (because it's digging into
> data structures that have changed repeatedly), and I'm not sure how much
> I trust it anyway.  So I'm leaning towards just doing
>
> +               if (colno == 0)
> +                       appendStringInfoString(buf, " *");
>
> at least till such time as somebody shows a case where this isn't good
> enough.
>

Well here's a contrived example with grouping:

create table nocols();
create table somecols(a int, b int);
create view v as select exists(select nocols.* from nocols, somecols
group by somecols.a);

Simply turning that tlist into "*" makes the query invalid because
somecols.b doesn't appear in the group by clause. So in this case, it
needs to try to output a tlist that contains no columns.

Regards,
Dean


> Note that I wouldn't be thinking of this as something to back-patch
> at all, except that if someone did have a view that looked like this,
> they'd find that pg_dump output wouldn't restore.  You could construct
> scenarios where that could seem like a denial of service, particularly
> if the DBA wasn't smart enough to figure out what was wrong with his
> dump.  (And who wants to deal with such a thing at 4AM anyway ...)
>
> Comments?
>
>                         regards, tom lane
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Extension Templates S03E11
Следующее
От: Sameer Thakur
Дата:
Сообщение: Re: pg_stat_statements: calls under-estimation propagation