Re: Import: empty string and expression
От | Dave Page |
---|---|
Тема | Re: Import: empty string and expression |
Дата | |
Msg-id | 937d27e10902260132o1b94436o1d01fc890b81f325@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Import: empty string and expression (Quan Zongliang <quanzongliang@gmail.com>) |
Ответы |
Re: Import: empty string and expression
|
Список | pgadmin-hackers |
On Thu, Feb 26, 2009 at 9:17 AM, Quan Zongliang <quanzongliang@gmail.com> wrote: >> Right - so why do we need to escape anything in the expression? >> Shouldn't the user just be able to free-type whatever they want (in >> the same way they would if they were writing the expression as part of >> a query in the Query Tool? > I have to convert column names in expression to data for every row > before generate statement. Without escape char, I don't know > what is column-name, what is lexical. Once the user want to input > a lexical same as one of column-names, confusion occur. > > For example, with CSV row "A1,B1,C1,D1": > 'Column #1' || <Column #3> will be converted to 'Column #1' || 'C1' > The first is a lexical, the second is CSV column. > > But 'Column #1' || Column #3 can't be converted properly. Oh I see what you mean. Let's just use some notation like: "$(#1) || substring($(#3) from 2 for 1)" for positional notation, or "$(col_1) || substring($(col_3) from 2 for 1)" for name based. You can't have an operator called $( so there shouldn't be any collision with PG operators in the expression - and to allow the user to include a constant of $(...), we can tell them to use \$(...} or $$(...) -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
В списке pgadmin-hackers по дате отправления: