Re: Unable to prepare a statement when the object names contain more than one $ symbol
От | Michael Paesold |
---|---|
Тема | Re: Unable to prepare a statement when the object names contain more than one $ symbol |
Дата | |
Msg-id | 47177F0E.6020601@gmx.at обсуждение исходный текст |
Ответ на | Re: Unable to prepare a statement when the object names contain more than one $ symbol (Michael Paesold <mpaesold@gmx.at>) |
Ответы |
Re: Unable to prepare a statement when the object names contain
more than one $ symbol
|
Список | pgsql-jdbc |
Michael Paesold wrote: > Hi Kris, > > sorry for not coming back to this earlier. Yeah, this is no real > solution. I thought about checking the character directly before the > dollar quote. But I have not had the time to look at the grammer if that > is enough to fix all error cases... I will do so tomorrow. Well, I think we have several simple options (apart from implementing a real parser in the driver ;-)... 1) In parseDollarQuotes(), we look at the character directly before the $-char and compare it against all valid identifier characters. If it is, we don't have a possible dollar-quote start: From scan.l: ident_start [A-Za-z\200-\377_] ident_cont [A-Za-z\200-\377_0-9\$] 2) Same concept as 1), but instead create a new method parseIdentifier() in the Parser class that would be used to detect and "skip" all regular keywords and identifiers in the query string, and therefore avoid the current problem. Seems like a performance loss though, because we would do more checks on each character. 3) Again in parseDollarQuotes(), we look at the character directly before the $-char and see if it is an *allowed* character before a dollar-quote. But what is allowed? Operators, a comma, parenthesis, etc. ... this is much harder to get right. Looking at gram.y and scan.l (...but I'm no expert) I can't see another case of a dollar-character that I missed, except the one allowed in ident_cont... so option 1) seems like the easiest solution. I will send a patch implementing option 1 shortly. Regarding your patch: I'm not sure if we should apply it, too. You will probably get a different error messages in case of an unterminated dollar quote. I haven't looked at the possible results. My original reasoning was that if there is an unterminated quote, this should not cause us parsing what is inside the quotes. So I would leave it as-is. Another option would be to throw an "unterminated dollar-quote" exception directly in the driver, which would be more helpful in some cases. Best Regards Michael Paesold
В списке pgsql-jdbc по дате отправления: