Added to open items list:
* fix dollar quoting problems in pg_restore
---
Philip Warner wrote:
CREATE FUNCTION xxx() RETURNS integer
AS $$ begin return 1;
2004-08-12 01:38:48
Philip Warner said:
At 12:15 PM 12/08/2004, Tom Lane wrote:
You might need to bite the bullet and implement a flex
lexer.
I'd like to avoid this if I can; AFAICT, for statement detection on
pg_restore, I can require white space before the $tag. Since I also
skip over all quoted text, the
Andrew Dunstan [EMAIL PROTECTED] writes:
I had a thought that might short-circuit this - do we even need pg_dump to
use dollar quoting for non-text output, such as is required by pg_restore?
That's a possibility, but I'd rather work around it by finding a way for
pg_restore not to need to parse
At 11:42 PM 12/08/2004, Tom Lane wrote:
That's a possibility, but I'd rather work around it by finding a way for
pg_restore not to need to parse the dollar-quoted literal in the first
place.
Two possibilities:
1) Parse the tags (I have the code working): it's not that hard, the only
trick bit
CREATE FUNCTION xxx() RETURNS integer
AS $$ begin return 1;
2004-08-12 01:38:48 ESTzzz,birds: ERROR: unterminated dollar-quoted
string at or near $$ begin return 1; at character 115
Just realized the problem; pg_restore uses a trivial parser to work out
when statements
Just found this:
createdb zzz
createlang plpgsql zzz
psql zzz
create function xxx() returns integer as
$$ begin return 1; end; $$
language plpgsql;
\q
pg_dump -Fc zzz zzz.bck
dropdb zzz
createdb zzz
createlang plpgsql zzz
pg_restore
Philip Warner [EMAIL PROTECTED] writes:
Just realized the problem; pg_restore uses a trivial parser to work out
when statements start/end. It knows about quotes but not about dollar-quotes.
Blech. Do you have time to fix it?
regards, tom lane
Philip Warner [EMAIL PROTECTED] writes:
Con someone confirm how dollar quoting works:
'$[tag]$'
where tag is alpha chars? any chars? \n? \r?
IIRC the tag is either empty or anything that looks like a
(dollar-sign-less) identifier. But check the rules in scan.l to be sure.
Is there any
At 12:15 PM 12/08/2004, Tom Lane wrote:
IIRC we tried to do ad-hoc code for dollar quoting in psql, and gave it
up as a bad job. You might need to bite the bullet and implement a flex
lexer.
Looks like the psql side of things is not ideal (see other post).
Any idea how backslashes should handled
At 12:15 PM 12/08/2004, Tom Lane wrote:
Why exactly does pg_restore need to parse the SQL anyway?
It just looks for complete statements. From memory it relates to the
possibility that TOC entries can have more than one statement, or it may
relate to handling COPY statements. I think it has to
Philip Warner [EMAIL PROTECTED] writes:
Any idea how backslashes should handled in and out of the tag?
Backslashes aren't legal in the tag, I'm quite sure. In the body of the
quoted string they are not special in any way.
regards, tom lane
Philip Warner [EMAIL PROTECTED] writes:
At 12:15 PM 12/08/2004, Tom Lane wrote:
Why exactly does pg_restore need to parse the SQL anyway?
It just looks for complete statements. From memory it relates to the
possibility that TOC entries can have more than one statement, or it may
relate to
At 12:42 PM 12/08/2004, Tom Lane wrote:
Hm. But we could assume that a COPY will be all by itself in a TOC
entry, couldn't we?
Maybe. I know I hit a couple of nasty examples in the original code. Isn't
the COPY combined with the data? If so, we still have to scan for it's end.
The existing
Philip Warner [EMAIL PROTECTED] writes:
At 12:42 PM 12/08/2004, Tom Lane wrote:
Hm. But we could assume that a COPY will be all by itself in a TOC
entry, couldn't we?
Maybe. I know I hit a couple of nasty examples in the original code. Isn't
the COPY combined with the data? If so, we still
At 12:15 PM 12/08/2004, Tom Lane wrote:
You might need to bite the bullet and implement a flex
lexer.
I'd like to avoid this if I can; AFAICT, for statement detection on
pg_restore, I can require white space before the $tag. Since I also skip
over all quoted text, the bodies of functions are
15 matches
Mail list logo