SQL INSERT bug with 6.5.3 and 7.0.2

John Gotts wrote:

We're experiencing a problem with the parser with both 6.5.3 and 7.0.2.

ERROR: parser: parse error at or near "position"
fmfts=# insert into contact_people (user_id,name,"position",email_address) v
alues ('jgotts','hello',null,null);
INSERT 20402 1

The problem also appears with libpq.

Any idea why this would occur?

POSITION is a SQL reserved word.

e.g.:
SELECT POSITION ('bc' IN 'abcd');
strpos
--------
2
(1 row)

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Honour thy father and mother; which is the first
commandment with promise; That it may be well with
thee, and thou mayest live long on the earth."
Ephesians 6:2,3

In message <Pine.LNX.4.20.0006251829460.6484-100000@tacdyn.com>, "Robert J. Spr
awls" writes:

On Sun, 25 Jun 2000, John Gotts wrote:

JG>We're experiencing a problem with the parser with both 6.5.3 and 7.0.2.

JG>The following is with 7.0.2. 6.5.3 is similar.

JG>umpire(rc3.d)% psql -u fmfts
JG>psql: Warning: The -u option is deprecated. Use -U.
JG>...
JG>fmfts=# CREATE TABLE "contact_people" (
JG>fmfts(# "user_id" character(30),
JG>fmfts(# "account_id" character(30),
JG>fmfts(# "exchange_id" character(30),
JG>fmfts(# "isin_code" character(30),
JG>fmfts(# "symbol" character(30),
JG>fmfts(# "name" character(30),
JG>fmfts(# "position" character(30),
JG>fmfts(# "email_address" character(30));

Why are you enclosing the field names in quotes? That isn't neccessary.

This is just a cut from pg_dump and a paste into psql of the exact SQL
statement. I doubt pg_dump would get this wrong.

My understanding is that quote characters allow you to have fields with capital
letters and spaces, but using them unnecessarily is harmless.

JG>fmfts=# insert into contact_people (user_id,name,position,email_address) va
lues ('jgotts','hello',null,null);
JG>ERROR: parser: parse error at or near "position"
JG>fmfts=# insert into contact_people (user_id,name,"position",email_address)
values ('jgotts','hello',null,null);
JG>INSERT 20402 1

JG>The problem also appears with libpq.

JG>Any idea why this would occur?

It could be fallout from enclosing the field names in quotes, but why it
doesn't fail on all of them I don't know. Try without the quotes in the
table definition.

fmfts=# CREATE TABLE contact_people (user_id character(30), account_id character(30), exchange_id character(30), isin_code character(30), symbol character(30), name character(30), position character(30), email_address character(30));
ERROR: parser: parse error at or near "position"

The plot thickens...

This is looking more and more like a bug in PostgreSQL's SQL parser.

John

--
John GOTTS <jgotts@linuxsavvy.com> http://www.linuxsavvy.com/staff/jgotts

In message <200006252355.e5PNtKe18458@linda.lfix.co.uk>, "Oliver Elphick" write
s:

John Gotts wrote:

We're experiencing a problem with the parser with both 6.5.3 and 7.0.2.

ERROR: parser: parse error at or near "position"
fmfts=# insert into contact_people (user_id,name,"position",email_address)

v

alues ('jgotts','hello',null,null);
INSERT 20402 1

The problem also appears with libpq.

Any idea why this would occur?

POSITION is a SQL reserved word.

e.g.:
SELECT POSITION ('bc' IN 'abcd');
strpos
--------
2
(1 row)

Shouldn't the parser then also reject "position"?

John

--
John GOTTS <jgotts@linuxsavvy.com> http://www.linuxsavvy.com/staff/jgotts

John Gotts <jgotts@ww2.tqstats.com> writes:

fmfts=# insert into contact_people (user_id,name,position,email_address) values ('jgotts','hello',null,null);
ERROR: parser: parse error at or near "position"
fmfts=# insert into contact_people (user_id,name,"position",email_address) values ('jgotts','hello',null,null);
INSERT 20402 1

POSITION is an SQL reserved word. If you want to use it as a column
name, you can, but you'll have to double-quote it every time you use it.

regards, tom lane

POSITION is a SQL reserved word.

Shouldn't the parser then also reject "position"?

No (if I read the question correctly), since double-quoted identifiers
do not conflict with reserved words. But then, as Tom pointed out, you
will have to use the double-quotes just about everywhere.

- Thomas