Re: BUG #7838: pg_dump major bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jan(dot)mate(at)inf-it(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7838: pg_dump major bug
Date: 2013-01-30 17:31:13
Message-ID: 9691.1359567073@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

jan(dot)mate(at)inf-it(dot)com writes:
> I created a very simple example to reproduce the problem (looks like it is a
> pg_dump problem). Here are the links to files used in my example:
> http://www.inf-it.com/fixes/postgres-bugreport/test.sql

Huh. That's not pg_dump's fault --- it's a grammar bug. The server
should accept something like

select ((select array[1,2]))[1];

but it does not. I see that you dodged the grammar bug in your view
definition by inserting a useless cast:

select ((select array[1,2])::int[])[1];

but you shouldn't have had to do that. The useless cast is omitted when
the view definition is regurgitated (indeed it's not there in the
internal form at all), and then the parser fails on that version of the
query text.

This seems to be easy to fix with one more grammar production to cover
the case of "c_expr ::= select_with_parens indirection". But I'm
surprised we've not heard complaints before, because this area of the
grammar has been like that for a very long time.

Will fix, thanks for the report!

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message digoal 2013-01-31 09:31:33 BUG #7840: PostgreSQL 9.3 devel select for no key share lock bug?
Previous Message Peter Eisentraut 2013-01-30 14:28:43 Re: BUG #7796: LC_MESSAGES