Re: A couple of issues with psql variable substitution
От | Robert Haas |
---|---|
Тема | Re: A couple of issues with psql variable substitution |
Дата | |
Msg-id | CA+TgmoZ9i-pcEEgM8Vt6v66Ezkw0OiFZ-CU-5+6poytGmgavnw@mail.gmail.com обсуждение исходный текст |
Ответ на | A couple of issues with psql variable substitution (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: A couple of issues with psql variable substitution
|
Список | pgsql-hackers |
On Thu, Aug 25, 2011 at 12:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > On my way to do something else entirely, I came across a couple of > things that are not very nice about psql's lexer: > > 1. Somebody broke the no-backtracking property back in 9.0 while adding > quoted variable substitution. According to the flex manual, use of > backtracking creates a performance penalty. We once measured the > backend's lexer as being about a third faster with backtrack avoidance, > and presumably it's about the same for psql's. This is not hard to fix, > but should I consider it a bug fix and back-patch? We've not had > complaints about psql getting slower as of 9.0. That may well have been me. How would I have known that I broke it? Also, how invasive is the fix? > 2. The lexer rules associated with variable substitution think that > variable names can consist only of ASCII letters and digits (and > underscores). The psql manual is noncommittal about whether non-ASCII > characters are allowed, but a reasonable person would think that the > rules ought to be the same as the backend's idea of what an identifier > is. Does anybody have a problem with improving that? Nope. Or at least, I don't. > (I'm not > proposing this part as a bug fix, because it does look a little bit > more invasive to fix, because of the way psql deals with unsafe > multibyte encodings.) +1 for not back-patching this part. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: