Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 31 Aug 2006 10:53:29 +0200
From: "Bernt M. Johnsen" <Bernt.Johnsen@Sun.COM>
Subject: Re: SQL Parser failing on NULL column contraint
In-reply-to: <44F67DEB.2040103@xtra.co.nz>
Sender: Bernt.Johnsen@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Reply-to: Bernt.Johnsen@Sun.COM
Message-id: <44F6A389.7020409@Sun.COM>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: multipart/signed;
 boundary=------------enig3B37DF953C4B0D66C367971C;
 protocol="application/pgp-signature"; micalg=pgp-sha1
References: <44F3087F.1020006@intland.com> <44F34597.4090902@gmail.com>
 <ee564160608291908sc0ba1abi20b5614d9cf503fa@mail.gmail.com>
 <44F587AA.8060007@xtra.co.nz> <44F5AE95.2010907@amberpoint.com>
 <44F67DEB.2040103@xtra.co.nz>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)


--------------enig3B37DF953C4B0D66C367971C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I can't see any reason why anyone would spend time on this issue.

1) "NULL" is not a constraint. All columns are nullable by default
   (SQL standard and in all SQL databases to my knowledge).

2) It will not add any new functionality.

3) You will not gain anything in speed, resource usage etc.

4) By removing the "NULL constraint" from your create statements, they
   will work with Derby and be portable back to the database that
   allowed them (if it is a reasonable implementation of SQL).

5) The SQL standard does not allow this syntax, so by incorporating it
   into Derby we run the risk that some uses it and creates SQL
   statements that are not portable to other databases.

So, I wonder: Why bother?

Duncan Groenewald wrote:
> Thanks - is there any documentation on how the parser works and
> explaining what is the sqlgrammer.jj file is and how is it used, etc.
>
> Duncan
>
> Bryan Pendleton wrote:
>> Duncan Groenewald wrote:
>>> Any chance someone can explain how I could modify the parser (or
>>> whatever) to be able to handle the NULL constraint ?
>>
>> Beware: I haven't tried this, but you could have a look at
>> java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj and
>> experimentally try to modify it for yourself.
>>
>> In terms of the modifications, I think you'll want to look at the
>> subroutine columnConstraint(), and observe how the explicitNotNull
>> and explicitNull flags are handled.
>>
>> Notice that there is an explicit parser block for
>>
>>   <NOT> <NULL>
>>
>> I think you'll either want to add a second explicit parser block for
>>
>>   <NULL>
>>
>> or modify the existing one to
>>
>>   [<NOT>] <NULL>
>>
>> and either way you want to make sure that you manage the explicitNull
>> and explicitNotNull flags properly, and that you call setNullability()=

>> on the dataTypeDescriptor to record the user's NULL / NOT NULL choice.=

>>
>> Hope this helps,
>>
>> bryan
>>
>>
>>
>


--=20
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway


--------------enig3B37DF953C4B0D66C367971C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE9qOMlFBD9TXBAPARAqL4AJ0VINya2GxzNkyXkWsLPtnP/7ENZACdHYHt
fdDr9Fpf7xCmM9Eg3Ih6zG0=
=zDc2
-----END PGP SIGNATURE-----

--------------enig3B37DF953C4B0D66C367971C--