[
https://issues.apache.org/jira/browse/DERBY-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735411#action_12735411
]
Suran Jayathilaka commented on DERBY-712:
-----------------------------------------
Posting some question I had and the answers given by Rick.
* Like CreateTriggerNode etc, why isn't there a CreateFunctionNode? the
functionDefinition() method is using the CreateAliasNode class.
Good point. CREATE FUNCTION is a good template from the perspective of the
parser but maybe a bit confusing from the perspective of the data structures.
Derby SQL routines (functions and procedures) are called Aliases internally.
This is because functions and procedures used to be much lighter-weight
objects. Originally, Derby functions and procedures were just names (aliases)
for user-coded static java methods, and declaring them was just a simple matter
of binding a Derby name to the external code. This, however, is not the ANSI
syntax for declaring functions and procedures. Today, Derby uses the ANSI
language for declaring functions and procedures, which means that functions and
procedures are much more heavy-weight than the original aliases were.
* How are the various jj_2_*() mthods in SQLParser used?
* In SQLParser, What's the sue of the jj_la1_* arrays?
Ah, looks like you are poking around in SQLParser. Don't bother with that file.
The grammar lives in sqlgrammar.jj, a yacc-like grammar which is much easier to
understand and extend. We use the javacc grammar generator to turn the
sqlgrammar.jj source into a number of generated files, one of which is the
barely readable SQLParser which you're looking at right now. Let me know if you
need help understanding sqlgrammar.jj. It's fairly straightforward if you are
familiar with yacc-style grammars but you may need some pointers if you haven't
worked on one of these grammars before.
> Support for sequences
> ---------------------
>
> Key: DERBY-712
> URL: https://issues.apache.org/jira/browse/DERBY-712
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Environment: feature request
> Reporter: Tony Dahbura
> Assignee: Suran Jayathilaka
> Fix For: 10.6.0.0
>
> Attachments: altertable.diff, catalogs_a.patch, catalogs_b.patch,
> catalogs_c.patch, catalogs_d.patch, catalogs_e.patch, catalogs_f.patch,
> catalogs_f_2.patch, catalogs_g.diff, catalogs_h.diff, SequenceGenerator.html
>
>
> Would like to see support added for sequences. This would permit a select
> against the sequence to always obtain a ever increasing/decreasing value.
> The identity column works fine but there are times for applications where the
> application needs to obtain the sequence number and use it prior to the
> database write. Subsequent calls to the table/column would result in a new
> number on each call.
> SQL such as the following:
> SELECT NEXT VALUE FOR sequence_name FROM sometable ; would result in a next
> value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
