RE: [INTERFACES] parser: parse error at or near... with create ta ble

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(dot)mengelbier(at)clinicaldatacare(dot)com
Web http://www.clinicaldatacare.com