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
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 |