Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

On 09/03/16 17:59, Lionel Elie Mamane wrote:
> On Tue, Mar 08, 2016 at 08:44:03PM +0000, Wols Lists wrote:
> > On 08/03/16 13:32, Lionel Elie Mamane wrote:
>
> > > At this point, I'd say, even more strongly than usual: the one that
> > > will do it will decide. Upgrading to a modern Java-based database
> > > would maybe not be that bad after all...
>
> > Sounds like I'd better get my finger out then!
>
> > IF I can get the basics in place (and to be honest it is a big if),
> > are other people prepared to muck in and help with the bits I can't
> > do?
>
> I'll answer a different question: Will Lionel, under his policy of
> "the one that will do it will decide", merge the patch?
>
> The answer is:
>
> If it is a well-maintained RDBMS that is reasonably featureful and
> solid, that doesn't bring us in other directions than "the usual
> suspects of the external ones" (MariaDB, PostgreSQL, Microsoft SQL
> Server, H2, HSQLDB2, etc), that it does not introduce undue
> incompatibilities (or difficulties in maintaining compatibility with
> those), that the SQL dialect and behaviour is reasonably close to the
> "common ground" between the "usual suspects", etc. Then yes, I will
> merge the patch.

Well, I did say Pick is a NoSQL database ...

Thing is, does "No" stand for "No" or for "Not Only"?
> If the RDBMS engine is self-implemented, then it has to come with a
> strong commitment to maintaining it, preferably animating a (future)
> development community around it.
That is very much the intent ...
> Also, we are not forced to have only one embedded database format, we
> can have several, so if several people do the work, we can merge the
> several ones.
>
>
> Now, specifically, duckduckgo-ing for "Pick" does not bring the
> expected results, so if you could give me some links to see what you
> are talking about? Thanks.
See my response to your next post.

Cheers,
Wol