I've tried PLDOC and found it to be really great, as I had most of the documentation correct without any modification in my source code. Really a great and definitely usefull utility.
I also tried the night build dated 9/june/04 juste to see the main differences and I happily saw that the table "comments" are now handled.
I still have a little problem concerning the storage clauses of my table creation scripts.
Is there something planned concerning this ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, this make me think of something.
Why don't you use the grammar definition provided by Oracle in its documentation ?
Wouldn't it be a lot easier than trying to redefine it on your own ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, do you think I'm trying to define my own SQL grammar ? :)))
The problem is, there is no official and complete (PL)SQL grammar provided by Oracle. They maybe don't even have one.
The "grammar" that is in PL/SQL Developer's Guide is incomplete and sometimes even incorrect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ironically, the storage clause that started this is a good example of the documentation not matching reality. The CREATE TABLE syntax suggests some constraints on the sequencing of physical properties that I don't believe is enforced by the parser. It would also be VERY time-consuming AT LEAST to convert ALL those railroad syntax diagrams into a machine-readable form such as BNF that could be plugged into a generic parser (and I don't think Oracle's textual descriptions are sufficiently rigorous in their construction to be used instead).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, yes.
I was mainly thinking that using those railroad syntax diagrams would allow to be sure not to forgot some parts of the syntax.
I absolutely agree concerning the time it would take to integrate all these information. I just don't agree on the fact that not doing it is quicker ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've tried PLDOC and found it to be really great, as I had most of the documentation correct without any modification in my source code. Really a great and definitely usefull utility.
I also tried the night build dated 9/june/04 juste to see the main differences and I happily saw that the table "comments" are now handled.
I still have a little problem concerning the storage clauses of my table creation scripts.
Is there something planned concerning this ?
Yes, sure.
I did not have a storage clauses in my own scripts,
that's why I forgot to handle them.
Well, this make me think of something.
Why don't you use the grammar definition provided by Oracle in its documentation ?
Wouldn't it be a lot easier than trying to redefine it on your own ?
Hmm, do you think I'm trying to define my own SQL grammar ? :)))
The problem is, there is no official and complete (PL)SQL grammar provided by Oracle. They maybe don't even have one.
The "grammar" that is in PL/SQL Developer's Guide is incomplete and sometimes even incorrect.
Ironically, the storage clause that started this is a good example of the documentation not matching reality. The CREATE TABLE syntax suggests some constraints on the sequencing of physical properties that I don't believe is enforced by the parser. It would also be VERY time-consuming AT LEAST to convert ALL those railroad syntax diagrams into a machine-readable form such as BNF that could be plugged into a generic parser (and I don't think Oracle's textual descriptions are sufficiently rigorous in their construction to be used instead).
Yes, those are exactly the problems I face
Well, yes.
I was mainly thinking that using those railroad syntax diagrams would allow to be sure not to forgot some parts of the syntax.
I absolutely agree concerning the time it would take to integrate all these information. I just don't agree on the fact that not doing it is quicker ;)
Well, you're right, of course...
I just thaught it would be easier to follow the schemas provided in the Oracle Docs...