Skip site navigation (1) Skip section navigation (2)

Re: Import: empty string and expression

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Quan Zongliang <quanzongliang(at)gmail(dot)com>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Import: empty string and expression
Date: 2009-02-26 09:32:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On Thu, Feb 26, 2009 at 9:17 AM, Quan Zongliang <quanzongliang(at)gmail(dot)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:

In response to


pgadmin-hackers by date

Next:From: Guillaume LelargeDate: 2009-02-26 09:45:08
Subject: Re: Server Status window work
Previous:From: Quan ZongliangDate: 2009-02-26 09:17:57
Subject: Re: Import: empty string and expression

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group