Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wx1jQ-0007P2-TM for pgsql-docs@arkaria.postgresql.org; Tue, 17 Jun 2014 22:19:57 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wx1jQ-0004K2-8S for pgsql-docs@arkaria.postgresql.org; Tue, 17 Jun 2014 22:19:56 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Wx1jP-0004Ju-AO for pgsql-docs@postgresql.org; Tue, 17 Jun 2014 22:19:55 +0000 Received: from mail-lb0-x22c.google.com ([2a00:1450:4010:c04::22c]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Wx1jM-000453-AJ for pgsql-docs@postgresql.org; Tue, 17 Jun 2014 22:19:53 +0000 Received: by mail-lb0-f172.google.com with SMTP id c11so531lbj.31 for ; Tue, 17 Jun 2014 15:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=hLEmkCNwPuVjzp/MGHTd3y857bSHUigOpNlLtvqSXLU=; b=bFjkyqlqyu3t/HIIZrJGw4aiO/l0EmatxBupUApIJlqIn98Eq4QY9YfX7db9JLYeCR d6a7HA/+tl31NU2lYuay2JGI9KrYosdvZTZCs8LsnMzgLiKMvqMvj4KrLD38IPteUm20 LHK8JIK1Wkz5WxgtxNAuqx518P6BiBFK5VXfBuM9bJt0bgtxLfB5qNTimNh37o1S/kBj WpP7BA/ynONbwOg/oZEY3VnWCtmrSFM70AIxvEKdxXMkTEMUSqTELjxRrDrrEwAJ/LcQ u3p26o4elArQ6VoTMAapqF8ctFpq0HXgrk0mJb4aDY8yOt+2PS0D3bg3VcsjHFNklrJi H43w== X-Received: by 10.112.63.162 with SMTP id h2mr8067244lbs.45.1403043589920; Tue, 17 Jun 2014 15:19:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.62.177 with HTTP; Tue, 17 Jun 2014 15:19:29 -0700 (PDT) In-Reply-To: <814.1402978354@sss.pgh.pa.us> References: <814.1402978354@sss.pgh.pa.us> From: =?UTF-8?Q?S=C3=A9rgio_Saquetim?= Date: Tue, 17 Jun 2014 19:19:29 -0300 Message-ID: Subject: Re: Lexical Structure - String Constants Cc: pgsql-docs@postgresql.org Content-Type: multipart/alternative; boundary=001a1133d3fec81e1204fc0f8a1c X-Pg-Spam-Score: -1.0 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org --001a1133d3fec81e1204fc0f8a1c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > "10e" is not a valid number, just like the manual says. But "10" is a > valid number, and "e" is a valid column alias, so this is equivalent > to "SELECT 10 AS e". There's no requirement for white space between > adjacent tokens, if the tokens couldn't validly be run together into > one token. Thanks Tom, I haven't noticed that fact. I'll refactor my lexer to deal with that. Regards, S=C3=A9rgio Saquetim --001a1133d3fec81e1204fc0f8a1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> "10e&q= uot; is not a valid number, just like the manual says. =C2=A0But "10&q= uot; is a
> valid number, and "e" is a valid column alias, = so this is equivalent
> to "SELECT 10 AS e". =C2=A0There's no requirement for wh= ite space between
> adjacent tokens, if the tokens couldn't valid= ly be run together into
> one token.

Thanks Tom,=C2=A0<= div>
I haven't notic= ed that fact. I'll refactor my lexer to deal with that.

Regards,

S=C3=A9rgio Saquetim
=C2=A0
 --001a1133d3fec81e1204fc0f8a1c--