Thread: BUG #13655: Incorrect Syntax Error
The following bug has been logged on the website:
Bug reference: 13655
Logged by: David
Email address: stormbyte@gmail.com
PostgreSQL version: 9.4.4
Operating system: Gentoo Linux
Description:
When using field names with "", and custom data type, with its name also
with "", a syntax error is triggered in CREATE TABLE when tab character is
used instead of spaces.
To reproduce, create a sql file with: (Insert tab and NOT space when <TAB>
is specified)
CREATE TYPE "GPSPoint" AS ("lat" DECIMAL(9,6), "lon" DECIMAL(9,6));
CREATE TABLE "TestTable" ("testGPS"<TAB>"GPSPoint" NOT NULL);
Save it, and copy/paste to psql, you will see an syntax error near NOT.
That is workarounded by inserting <SPACE> before or instead of <TAB>, but
should not trigger any syntax error, as the same syntax works for bundled
types, so the following does not fail:
CREATE TABLE "TestTable" ("test"<TAB>SMALLINT NOT NULL);
This is a low priority bug, but a bit annoying
On Thu, Oct 1, 2015 at 5:25 AM, <stormbyte@gmail.com> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 13655
> Logged by: David
> Email address: stormbyte@gmail.com
> PostgreSQL version: 9.4.4
> Operating system: Gentoo Linux
> Description:
>
> When using field names with "", and custom data type, with its name also
> with "", a syntax error is triggered in CREATE TABLE when tab character is
> used instead of spaces.
>
> To reproduce, create a sql file with: (Insert tab and NOT space when <TAB>
> is specified)
> CREATE TYPE "GPSPoint" AS ("lat" DECIMAL(9,6), "lon" DECIMAL(9,6));
>
> CREATE TABLE "TestTable" ("testGPS"<TAB>"GPSPoint" NOT NULL);
>
> Save it, and copy/paste to psql, you will see an syntax error near NOT.
>
> That is workarounded by inserting <SPACE> before or instead of <TAB>, but
> should not trigger any syntax error, as the same syntax works for bundled
> types, so the following does not fail:
> CREATE TABLE "TestTable" ("test"<TAB>SMALLINT NOT NULL);
>
> This is a low priority bug, but a bit annoying
As I feel this is not a bug. psql has the tab complete feature with
the help of readline library.
Means it tries fill the command if the user provides the tab key as input.
In the test given above, the query is translated as follows, because
of that reason only
it is giving problem.
CREATE TYPE "GPSPoint" AS ("lat" DECIMAL(9,6), "lon" DECIMAL(9,6));
CREATE TABLE "TestTable" ("testGPS"<TAB>"GPSPoint" NOT NULL);
In this tab character is taken as psql input and the query will turn
into as follows.
CREATE TABLE "TestTable" ("testGPS""GPSPoint" NOT NULL);
Two quoted separate strings next to each other turns into a single
string as follows.
CREATE TABLE "TestTable" ("testGPSGPSPoint" NOT NULL);
Because of the above case, it is leading to a problem.
If I written the query as follows it works similar like SMALLINT case,
CREATE TYPE GPSPoint AS ("lat" DECIMAL(9,6), "lon" DECIMAL(9,6));
CREATE TABLE "TestTable" ("testGPS"<TAB>GPSPoint NOT NULL);
CREATE TABLE "TestTable" ("testGPS"GPSPoint NOT NULL);
Does any one feels the documentation to be updated for such case?
Regards,
Hari Babu
Fujitsu Australia
On Wednesday, September 30, 2015, Haribabu Kommi <kommi.haribabu@gmail.com>
wrote:
> On Thu, Oct 1, 2015 at 5:25 AM, <stormbyte@gmail.com <javascript:;>>
> wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 13655
> > Logged by: David
> > Email address: stormbyte@gmail.com <javascript:;>
> > PostgreSQL version: 9.4.4
> > Operating system: Gentoo Linux
> > Description:
> >
> > When using field names with "", and custom data type, with its name also
> > with "", a syntax error is triggered in CREATE TABLE when tab character
> is
> > used instead of spaces.
> >
> > To reproduce, create a sql file with: (Insert tab and NOT space when
> <TAB>
> > is specified)
> > CREATE TYPE "GPSPoint" AS ("lat" DECIMAL(9,6), "lon" DECIMAL(9,6));
> >
> > CREATE TABLE "TestTable" ("testGPS"<TAB>"GPSPoint" NOT NULL);
> >
> > Save it, and copy/paste to psql, you will see an syntax error near NOT.
> >
> > That is workarounded by inserting <SPACE> before or instead of <TAB>, but
> > should not trigger any syntax error, as the same syntax works for bundled
> > types, so the following does not fail:
> > CREATE TABLE "TestTable" ("test"<TAB>SMALLINT NOT NULL);
> >
> > This is a low priority bug, but a bit annoying
>
> As I feel this is not a bug. psql has the tab complete feature with
> the help of readline library.
> Means it tries fill the command if the user provides the tab key as input.
>
>
Tab-completion should not interfere with script code provided
non-interactively on standard input, or in a script file loaded using -f or
\i
Not having tested this myself the OP is lacking in their description of how
exactly they are passing the SQL to psql. "Copy/paste to psql" is
decidedly unclear.
David J.
On Thu, Oct 1, 2015 at 11:56 AM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Wednesday, September 30, 2015, Haribabu Kommi <kommi.haribabu@gmail.com>
> wrote:
>>
>> On Thu, Oct 1, 2015 at 5:25 AM, <stormbyte@gmail.com> wrote:
>> > The following bug has been logged on the website:
>> >
>> > Bug reference: 13655
>> > Logged by: David
>> > Email address: stormbyte@gmail.com
>> > PostgreSQL version: 9.4.4
>> > Operating system: Gentoo Linux
>> > Description:
>> >
>> > When using field names with "", and custom data type, with its name also
>> > with "", a syntax error is triggered in CREATE TABLE when tab character
>> > is
>> > used instead of spaces.
>> >
>> > To reproduce, create a sql file with: (Insert tab and NOT space when
>> > <TAB>
>> > is specified)
>> > CREATE TYPE "GPSPoint" AS ("lat" DECIMAL(9,6), "lon" DECIMAL(9,6));
>> >
>> > CREATE TABLE "TestTable" ("testGPS"<TAB>"GPSPoint" NOT NULL);
>> >
>> > Save it, and copy/paste to psql, you will see an syntax error near NOT.
>> >
>> > That is workarounded by inserting <SPACE> before or instead of <TAB>,
>> > but
>> > should not trigger any syntax error, as the same syntax works for
>> > bundled
>> > types, so the following does not fail:
>> > CREATE TABLE "TestTable" ("test"<TAB>SMALLINT NOT NULL);
>> >
>> > This is a low priority bug, but a bit annoying
>>
>> As I feel this is not a bug. psql has the tab complete feature with
>> the help of readline library.
>> Means it tries fill the command if the user provides the tab key as input.
>>
>
> Tab-completion should not interfere with script code provided
> non-interactively on standard input, or in a script file loaded using -f or
> \i
Tab-completion doesn't change <TAB> characters if the file passed
using -f or \i.
> Not having tested this myself the OP is lacking in their description of how
> exactly they are passing the SQL to psql. "Copy/paste to psql" is decidedly
> unclear.
Tab-completion comes into picture only when user tries to write the query or
paste the query from a notepad with tab characters in it.
Regards,
Hari Babu
Fujitsu Australia
Haribabu Kommi <kommi.haribabu@gmail.com> writes:
> On Thu, Oct 1, 2015 at 11:56 AM, David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> On Wednesday, September 30, 2015, Haribabu Kommi <kommi.haribabu@gmail.com>
>> wrote:
>>> As I feel this is not a bug. psql has the tab complete feature with
>>> the help of readline library.
>>> Means it tries fill the command if the user provides the tab key as input.
>> Tab-completion should not interfere with script code provided
>> non-interactively on standard input, or in a script file loaded using -f or
>> \i
> Tab-completion doesn't change <TAB> characters if the file passed
> using -f or \i.
Yeah. I could not reproduce the reported error when feeding the file
to psql using "-f file", "<file", or "\i file". It is possible to get
it by pasting the given text into a terminal window, so that readline
can't tell that you didn't manually type the TAB.
Worth noting here is you can turn off readline with the -n option
to psql. I've done that sometimes when there was a reason not to want
TAB to act as command-completion.
regards, tom lane
El Thu, 01 Oct 2015 00:44:48 -0400 Tom Lane <tgl@sss.pgh.pa.us> escribi=C3=B3: > Haribabu Kommi <kommi.haribabu@gmail.com> writes: > > On Thu, Oct 1, 2015 at 11:56 AM, David G. Johnston > > <david.g.johnston@gmail.com> wrote: > >> On Wednesday, September 30, 2015, Haribabu Kommi > >> <kommi.haribabu@gmail.com> wrote: > >>> As I feel this is not a bug. psql has the tab complete feature > >>> with the help of readline library. > >>> Means it tries fill the command if the user provides the tab key > >>> as input. >=20 > >> Tab-completion should not interfere with script code provided > >> non-interactively on standard input, or in a script file loaded > >> using -f or \i >=20 > > Tab-completion doesn't change <TAB> characters if the file passed > > using -f or \i. >=20 > Yeah. I could not reproduce the reported error when feeding the file > to psql using "-f file", "<file", or "\i file". It is possible to get > it by pasting the given text into a terminal window, so that readline > can't tell that you didn't manually type the TAB. >=20 > Worth noting here is you can turn off readline with the -n option > to psql. I've done that sometimes when there was a reason not to want > TAB to act as command-completion. >=20 > regards, tom lane (resent to mailing list instead of simple reply) The real question here is: Since tab character triggers autocompletion (or hints), when copy/pasted it has no effect, but: Isn't it inconsistent that a thing like: "someField"SMALLINT works whether a thing like: "someField""SomeCustomType" is not working? Both forms have the exact same format: a field perfectly delimitated, and after a type for that field with no space nor separation, both seems legal to me, as parser knows exactly what is what (unlike the case below) (even if you write directly without spaces at all). I understand however, that using it without quoted (without delimitation), can cause a syntax error in case like: someFieldSMALLINT, but that's not the case. Anyway, everything has been said in this regard, just wanted to say this, as to my eyes, it's kind of inconsistent allow one case, but not allowing the other. David.
David <stormbyte@gmail.com> writes:
> Isn't it inconsistent that a thing like: "someField"SMALLINT works
> whether a thing like: "someField""SomeCustomType" is not working?
Well, you can debate how consistent it is, but that behavior is required
by SQL standard. Per spec, "foo""bar" is a single identifier containing
an embedded double quote (just one). It's not two adjacent tokens,
whereas "foo"keyword does represent two tokens.
regards, tom lane