RE: [INTERFACES] parser: parse error at or near... with create ta ble
От | Mengelbier, Magnus |
---|---|
Тема | RE: [INTERFACES] parser: parse error at or near... with create ta ble |
Дата | |
Msg-id | 81F0C610BC68D2118F110008C7242DE51EAB5B@luex1.clinicaldatacare.com обсуждение исходный текст |
Список | 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
В списке pgsql-interfaces по дате отправления:
Следующее
От: Peter MountДата:
Сообщение: Re: [INTERFACES] setTransactionIsolation support for JDBC driver (patch)