From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO |
Date: | 2016-07-12 22:10:27 |
Message-ID: | 11633.1468361427@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Mon, Jul 11, 2016 at 3:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> While we can certainly hack it by something along the lines of not
>> recognizing INTO when the first token was IMPORT, the whole thing
>> seems awfully messy and fragile. And it will certainly break again
>> the next time somebody decides that INTO is le mot juste in some new
>> SQL command. I wish we could think of a safer, more future-proof
>> solution. I have no idea what that would be, though, short of
>> deprecating INTO altogether.
> This is a natural consequence of having two
> almost-but-not-quite-the-same grammars handing the same shared
> language. There are a similar set of annoyances compiling C with a
> C++ compiler as we all know. In a perfect world, SQL procedural
> extensions would be a proper superset and we'd have *one* grammar
> handling everything. Among other niceties this would make moving
> forward with stored procedures a much simpler discussion. Well, C'est
> la vie :-D.
Yeah, I was just belly-aching ;-). Not much choice in the short term.
Fix pushed.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-07-12 22:41:22 | Re: Showing parallel status in \df+ |
Previous Message | Tom Lane | 2016-07-12 21:11:32 | Re: BUG #14245: Segfault on weird to_tsquery |