Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 042961FE6210 for ; Sun, 15 Jan 2012 04:02:54 -0400 (AST) Received: from lo.gmane.org ([80.91.229.12]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RmL3E-0005KI-Lh for pgsql-sql@postgresql.org; Sun, 15 Jan 2012 08:02:53 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RmL31-0008Ub-6j for pgsql-sql@postgresql.org; Sun, 15 Jan 2012 09:02:39 +0100 Received: from g224121126.adsl.alicedsl.de ([92.224.121.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jan 2012 09:02:39 +0100 Received: from tim by g224121126.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jan 2012 09:02:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: pgsql-sql@postgresql.org To: pgsql-sql@postgresql.org From: Tim Landscheidt Subject: Token separation Date: Sun, 15 Jan 2012 08:02:27 +0000 Organization: Lines: 44 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: g224121126.adsl.alicedsl.de Mail-Copies-To: never User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:RmPWHK4IN8uf1kbsGAiXihbSCR8= X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201201/56 X-Sequence-Number: 36227 Hi, I just tried to input a hexadecimal number in PostgreSQL (8.4) and was rather surprised by the result: | tim=# SELECT 0x13; | x13 | ----- | 0 | (1 Zeile) | tim=# SELECT 0abc; | abc | ----- | 0 | (1 Zeile) | tim=# The documentation says: | A token can be a key word, an identifier, a quoted identifi- | er, a literal (or constant), or a special character symbol. | Tokens are normally separated by whitespace (space, tab, | newline), but need not be if there is no ambiguity (which is | generally only the case if a special character is adjacent | to some other token type). Is this behaviour really conforming to the standard? Even stranger is what MySQL (5.1.59) makes out of it: | mysql> SELECT 0x40; | +------+ | | 0x40 | | +------+ | | @ | | +------+ | 1 row in set (0.00 sec) | mysql> SELECT 0abc; | ERROR 1054 (42S22): Unknown column '0abc' in 'field list' | mysql> Tim