Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-17 Thread Bruce Momjian
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-12 Thread Andrew Dunstan
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-12 Thread Tom Lane
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-12 Thread Philip Warner
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

[HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread Philip Warner
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

[HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread Philip Warner
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread Tom Lane
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread 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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread Philip Warner
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread Philip Warner
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread Tom Lane
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread 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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread Philip Warner
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread Tom Lane
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

Re: [HACKERS] pg_restore (libpq? parser?) bug in 8

2004-08-11 Thread Philip Warner
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