pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedparser: parse error at or near... with create table
6+ messages / 5 participants
[nested] [flat]
* parser: parse error at or near... with create table
@ 1999-07-30 14:58 Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>
1999-07-30 15:29 ` Re: [INTERFACES] parser: parse error at or near... with create table Thomas Lockhart <lockhart@alumni.caltech.edu>
1999-07-30 15:40 ` Re: [INTERFACES] parser: parse error at or near... with create table Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 6+ messages in thread
From: Mengelbier, Magnus @ 1999-07-30 14:58 UTC (permalink / raw)
To: pgsql-interfaces
Hello all !
We wonder if any one has experience from an error (which is probably a
newbie misstake on our part) that pops up when we are trying to create a
simple table with pgAccess in a postgreSQL database. We have recieved the
same type of error on more complex table builds. The message is ...
Error executing query
create table "asdfs" ("fds" serial NOT NULL )
PostgreSQL error message:
Error: parser: parse error at or near "not"
PostgreSQL status: PGRES_FATAL_ERROR
We are running ...
- PostgreSQL 6.5.1 on Red Hat Linux 6.0 ... we installed binaries downloaded
from posgresql.org and not compiled source code.
- pgAccess 0.96 on the same Red Hat Linux system as well as a Win95
computer. Win95 has tcl/tk 8.0 installed.
Thanks !
Magnus
________________________________________________________
Magnus Mengelbier
Technical Consultant
Clinical Data Care
S:t Lars v. 41
SE-222 70 LUND
SWEDEN
Phone +46 46 14 22 80
Fax +46 46 13 04 90
Email magnus.mengelbier@clinicaldatacare.com
Web http://www.clinicaldatacare.com
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] parser: parse error at or near... with create table
1999-07-30 14:58 parser: parse error at or near... with create table Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>
@ 1999-07-30 15:29 ` Thomas Lockhart <lockhart@alumni.caltech.edu>
1999-07-30 16:41 ` Re: [INTERFACES] parser: parse error at or near... with create table D'Arcy J.M. Cain <darcy@druid.net>
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Lockhart @ 1999-07-30 15:29 UTC (permalink / raw)
To: Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>; +Cc: pgsql-interfaces
> We wonder if any one has experience from an error (which is probably a
> newbie misstake on our part) that pops up when we are trying to create a
> simple table with pgAccess in a postgreSQL database. We have recieved the
> same type of error on more complex table builds. The message is ...
> Error executing query
> create table "asdfs" ("fds" serial NOT NULL )
> PostgreSQL error message:
> Error: parser: parse error at or near "not"
> PostgreSQL status: PGRES_FATAL_ERROR
By definition, the SERIAL type is NOT NULL, so I didn't bother
allowing that clause in the parser. If you would like to see this
feature documented, send patches on docs/src/sgml/datatype.sgml. Or
maybe we should allow it, but it *is* redundant ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] parser: parse error at or near... with create table
1999-07-30 14:58 parser: parse error at or near... with create table Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>
1999-07-30 15:29 ` Re: [INTERFACES] parser: parse error at or near... with create table Thomas Lockhart <lockhart@alumni.caltech.edu>
@ 1999-07-30 16:41 ` D'Arcy J.M. Cain <darcy@druid.net>
1999-07-30 18:13 ` Re: [INTERFACES] parser: parse error at or near... with create table Brendan McKenna <brendan@w3s.ie>
0 siblings, 1 reply; 6+ messages in thread
From: "D'Arcy" "J.M." Cain @ 1999-07-30 16:41 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: Magnus.Mengelbier@clinicaldatacare.com; pgsql-interfaces
Thus spake Thomas Lockhart
> > create table "asdfs" ("fds" serial NOT NULL )
> By definition, the SERIAL type is NOT NULL, so I didn't bother
> allowing that clause in the parser. If you would like to see this
> feature documented, send patches on docs/src/sgml/datatype.sgml. Or
> maybe we should allow it, but it *is* redundant ;)
Given that serial is currently a hack and we plan to implement a real
serial type, we should consider what the real type will do. Is it
still going to be special? Will it act exactly as it does now? Once
we determine that then we just make the parser accept what it will
need to accept then so that people can write their queries the way
they will have to then.
I guess the main question is, will we allow the serial type to be NULL.
If not will we allow the NOT NULL phrase anyway to simplify the grammar.
If yes to either then let's allow the phrase now.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] parser: parse error at or near... with create table
1999-07-30 14:58 parser: parse error at or near... with create table Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>
1999-07-30 15:29 ` Re: [INTERFACES] parser: parse error at or near... with create table Thomas Lockhart <lockhart@alumni.caltech.edu>
1999-07-30 16:41 ` Re: [INTERFACES] parser: parse error at or near... with create table D'Arcy J.M. Cain <darcy@druid.net>
@ 1999-07-30 18:13 ` Brendan McKenna <brendan@w3s.ie>
0 siblings, 0 replies; 6+ messages in thread
From: Brendan McKenna @ 1999-07-30 18:13 UTC (permalink / raw)
To: pgsql-interfaces
Hi,
My quick $0.02 worth...
:
: I guess the main question is, will we allow the serial type to be NULL.
: If not will we allow the NOT NULL phrase anyway to simplify the grammar.
: If yes to either then let's allow the phrase now.
:
I don't see how you can allow a serial value to be null, since that
would defeat the purpose of a serial (presuming there were more than one
NULL-valued serial in a table). I just don't see how, logically, a serial
could allow NULLs (even if it may be desirable in some cases).
On the other hand, I would allow the NOT NULL phrase, even though
it's redundant.
Brendan
--
Brendan McKenna
Technical Director Phone: +353-(0)61-338177 x4143
W3 Services Ltd. Fax: +353-(0)61-338065
Innovation Centre Email: brendan@w3s.ie
National Technological Park
Limerick
Ireland
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] parser: parse error at or near... with create table
1999-07-30 14:58 parser: parse error at or near... with create table Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>
@ 1999-07-30 15:40 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 6+ messages in thread
From: Tom Lane @ 1999-07-30 15:40 UTC (permalink / raw)
To: Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>; +Cc: pgsql-interfaces
"Mengelbier, Magnus" <Magnus.Mengelbier@clinicaldatacare.com> writes:
> Error executing query
> create table "asdfs" ("fds" serial NOT NULL )
> PostgreSQL error message:
> Error: parser: parse error at or near "not"
Hmm. NOT NULL is implied by SERIAL column type, so you can just omit
that clause, but it's irritating that the parser won't accept the
explicit specification. It looks like the grammar is set up to allow
no column constraints except PRIMARY KEY after SERIAL. That seems
unnecessarily restrictive...
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
* RE: [INTERFACES] parser: parse error at or near... with create ta ble
@ 1999-08-02 09:32 Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>
0 siblings, 0 replies; 6+ messages in thread
From: Mengelbier, Magnus @ 1999-08-02 09:32 UTC (permalink / raw)
To: pgsql-interfaces
Thanks for the comments everyone...
We did run into more create table problems that are similar to the one I
posted. pgAccess is a great start to a good postgresql interface so I would
like to add a few more comments to the pile.
Many responses noticed that SERIAL type is NOT NULL... should we let the
parser add NOT NULL to the create table statements? we also found that if
we added a number 8 in the size specification for a field, then we would
send SERIAL(8) to the parser and get the error message ... parser error at
or near "("...the same for DEFAULT values... parser error at or near
DEFAULT.
I think that adding some error checking or syntax checking around the parser
or even include a more restrictive parser grammar would solve the current
problem. I have not checked how extensive that work would be but it could
be worth it. If no one else has considered it or put in some hours, I could
give it a shot.
Thomas Lockhart wrote:
>By definition, the SERIAL type is NOT NULL, so I didn't bother
>allowing that clause in the parser. If you would like to see this
>feature documented, send patches on docs/src/sgml/datatype.sgml. Or
>maybe we should allow it, but it *is* redundant ;)
>
> - Thomas
It might be a good idea to document how the data types are implemented in
postgreSQL ... or how the parser interprets the interface. Not an official
request as of yet, but I would just like to see some comments for now.
Tom Lane wrote:
>Hmm. NOT NULL is implied by SERIAL column type, so you can just omit
>that clause, but it's irritating that the parser won't accept the
>explicit specification. It looks like the grammar is set up to allow
>no column constraints except PRIMARY KEY after SERIAL. That seems
>unnecessarily restrictive...
>
> regards, tom lane
>
Again... maybe 2 cents on the syntax checker or more restrictive parser.
D'Arcy J.M. Cain wrote:
>Given that serial is currently a hack and we plan to implement a real
>serial type, we should consider what the real type will do. Is it
>still going to be special? Will it act exactly as it does now? Once
>we determine that then we just make the parser accept what it will
>need to accept then so that people can write their queries the way
>they will have to then.
>
>I guess the main question is, will we allow the serial type to be NULL.
>If not will we allow the NOT NULL phrase anyway to simplify the grammar.
>If yes to either then let's allow the phrase now.
Depending on the definition of serial maybe... but then how should the
selections in general be restrictive? I think serial should never be NULL
by its definition. My experience just has serial to be an int4 that is
unique and incremental... nothing else... but then should serial type also
have the possibility to be a unique character string?
My 15 minutes of fame..
Magnus
________________________________________________________
Magnus Mengelbier
Technical Consultant
Clinical Data Care
S:t Lars v. 41
SE-222 70 LUND
SWEDEN
Phone +46 46 14 22 80
Fax +46 46 13 04 90
Email magnus.mengelbier@clinicaldatacare.com
Web http://www.clinicaldatacare.com
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~1999-08-02 09:32 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-07-30 14:58 parser: parse error at or near... with create table Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>
1999-07-30 15:29 ` Thomas Lockhart <lockhart@alumni.caltech.edu>
1999-07-30 16:41 ` D'Arcy J.M. Cain <darcy@druid.net>
1999-07-30 18:13 ` Brendan McKenna <brendan@w3s.ie>
1999-07-30 15:40 ` Tom Lane <tgl@sss.pgh.pa.us>
1999-08-02 09:32 RE: [INTERFACES] parser: parse error at or near... with create ta ble Mengelbier, Magnus <Magnus.Mengelbier@clinicaldatacare.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox