Re: pg_restore direct to database is broken for --insert dumps

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_restore direct to database is broken for --insert dumps
Date: 2012-01-06 00:01:23
Message-ID: 24669.1325808083@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Not easily: there could be newlines embedded in data strings or SQL
> identifiers. I'm not seeing any way around this except to restore the
> minimal lexing capability. One thing we could probably do is to
> restrict it to be used only when reading table data, and continue to
> assume that object creation commands can be emitted as-is. That would
> at least get us out of needing to parse dollar-quoted literals, which
> aren't used in the INSERT commands.

Attached is a patch that restores a much-simplified version of the mini
lexer; it deals only with the sorts of things that dumpTableData_insert
actually emits. Fixing the standard_conforming_strings issue turns out
to be really a one-liner, because the setting is in fact readily
available to this code. Maybe we should have done it that way to begin
with :-( ... though I admit to being glad to have gotten rid of the very
questionable dollar-quote-recognition code that was there before.

Barring objections to the approach, I'll apply and back-patch this
tomorrow.

regards, tom lane

Attachment Content-Type Size
pg-restore-lexer.patch text/x-patch 9.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2012-01-06 00:17:20 Re: random_page_cost vs seq_page_cost
Previous Message Peter Geoghegan 2012-01-06 00:01:10 Re: Progress on fast path sorting, btree index creation time