Come on Jim, don't you think that having a plug in architecture would be
good for a parser.

Why we may even have a low level language that is implemented in the
database (some sort of Binary Language Representation) that you can use
instead of the standard. We could have multiple incompatible or
semi-compatible SQL parsers as standard (perhaps just numbering the
dialects) while someone else works on Java or other language versions of the
underlying procedure language.

Why, I am sure we can even put in emulation of the operations(benchmarks) of
other database systems such as mongodb (external tables mapped to
/dev/null).

All kidding aside. A parser is tried and tested technology. Everyone has
written some form of parser in the past while parser generators are
available. If the system is written correctly, it could be made to be
easily generated. The big issue is, would it be used?

Our company just bought a series of other companies. They have systems on
old versions of Oracle, DB2 etc. Now the clients they use currently work,
but if we could keep their clients and rework the back end via
Firebird/Views and Procedures before we attack the front end, then there is
value there. Redesigning a back end and a front end combined with staff
retraining makes the project a non-starter. So we are faced with
maintaining legacy systems that don'r quite fit into our existing
infrastructure.

I am sure that we are not the only company who has faced a situation like
this. Having the option is a good thing, even if most users don't even
realize the power is there. (Filters are a good example of this, in all my
years I have never seen a firebird/interbase filter but once I found I had a
need, I had it written and it works well)

The decision would have to lie in the hands of the current developers
because there is not enough of a need on my part to finance it. So it
would have to be decided by those who consider such a tool important enough
to do the work.

On 8 September 2010 10:02, Jim Starkey <jstarkey@...> wrote:

>
>
> Ooo, ooo! Definitely a MySQL mode. But which of the dozens in
> mutually incompatible releases would that be? 5.0.x? 5.1.1? 5.1.y?
> 5.1.z? And home many of the dozens of incompatible operating modes
> would you include in each?
>
> MySQL expects that applications will require porting from x.y.z to
> x.y.<z+1>. Ugh. On the other hand, their users have been well
> trained. And they have to support and maintain a whole trail of old
> releases.
>
> My experience has been that users almost never, ever, port a working
> application from database A to database B. Looking at the issue from a
> NimbusDB planning perspective, we decided to stick with standard SQL and
> extensions of our own choosing on the assumption that we will be used
> for new applications doing forward, not old applications going backward.
>
> Do what you think is technically best.
>
>
> On 9/8/2010 6:32 AM, Dalton Calford wrote:
> > Are you suggesting a 'dialect oracle' ? How about a 'dialect mssql'?
> >
> > The big question is, should the parser be a plugin including some system
> > views that support various databases including their information schema?
> >
> > That would be powerful and allow firebird to be a drop in replacement of
> > many database backends.
> >
> > On 8 September 2010 05:44, marius adrian popa<mapopa@...<mapopa%40gmail.com>>
> wrote:
> >
> >>
> >> what happened to fyracle mode ?
> >>
> >> http://www.firebirdnews.org/docs/papers/fyracle_wsw.pdf
> >>
> >> i see some of it's components/features would be integrated in 3.0 (see
> >> the roadmap screeshot)
> >> it would be nice to have an oracle "mode" for migrations from oracle
> >>
> >> also it would be nicer to have full pl/sql support too
> >>
> >>
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> --
> Jim Starkey
> Founder, NimbusDB, Inc.
> 978 526-1376
>
>
>


[Non-text portions of this message have been removed]