On Sun, 16 Oct 2011 02:13:05 -0400, Steve Teale
wrote:
There's a discussion going on about Windows header files that has
discussed whether header files can be copyright.
Header files may be an issue with the database implementations. For
example my mysql.d is a straight translation of mysql.
On Mon, 17 Oct 2011 09:42:13 -0400, Steven Schveighoffer wrote:
> On Sun, 16 Oct 2011 02:13:05 -0400, Steve Teale
> wrote:
>
>> There's a discussion going on about Windows header files that has
>> discussed whether header files can be copyright.
>>
>> Header files may be an issue with the databa
Steve Teale Wrote:
> Hmm, I just did a quick check, and the MySQL client/server protocol is
> GPL also, so there's nowhere to go.
That was fixed.
> How do Python and PHP communicate with MySQL. Is it just that they have
> the clout to get a dispensation from MySQL AB?
MySQL license has FLOSS
On Mon, 17 Oct 2011 10:25:13 -0400, Steve Teale
wrote:
On Mon, 17 Oct 2011 09:42:13 -0400, Steven Schveighoffer wrote:
On Sun, 16 Oct 2011 02:13:05 -0400, Steve Teale
wrote:
There's a discussion going on about Windows header files that has
discussed whether header files can be copyright.
> A direct translation is a derivative work. So yes, it must be GPL.
>
> However, there must be ways around this. I believe headers have certain
> rules in most licenses.
>
Steve, do you think this provides any relief>
http://www.mysql.com/about/legal/licensing/foss-exception/
Steve
On Mon, 17 Oct 2011 10:56:45 -0400, Kagamin wrote:
Steve Teale Wrote:
Hmm, I just did a quick check, and the MySQL client/server protocol is
GPL also, so there's nowhere to go.
That was fixed.
That is good news! do you have a supporting link? Or is it something
that quietly went away?
Steven Schveighoffer Wrote:
> That is good news! do you have a supporting link? Or is it something
> that quietly went away?
http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocol&diff=5078&oldid=4374
I have shown this to a guy who was going to reimplement a mysql cli
Steve Teale Wrote:
> There's a discussion going on about Windows header files that has
> discussed whether header files can be copyright.
>
> Header files may be an issue with the database implementations. For
> example my mysql.d is a straight translation of mysql.h (and a couple of
> others)
On Mon, 17 Oct 2011 11:00:13 -0400, Steve Teale
wrote:
A direct translation is a derivative work. So yes, it must be GPL.
However, there must be ways around this. I believe headers have certain
rules in most licenses.
Steve, do you think this provides any relief>
http://www.mysql.com/ab
On Mon, 17 Oct 2011 11:11:37 -0400, Kagamin wrote:
Steven Schveighoffer Wrote:
That is good news! do you have a supporting link? Or is it something
that quietly went away?
http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocol&diff=5078&oldid=4374
I have shown thi
Kagamin wrote:
Steven Schveighoffer Wrote:
That is good news! do you have a supporting link? Or is it something
that quietly went away?
http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocol&diff=5078&oldid=4374
I have shown this to a guy who was going to reimplemen
Steven Schveighoffer Wrote:
> That is good! Since 2007, huh I'm surprised I could find no
> discussion on this
http://krow.livejournal.com/684068.html?thread=2674468#t2674468
Steve Teale Wrote:
> Header files may be an issue with the database implementations. For
> example my mysql.d is a straight translation of mysql.h (and a couple of
> others). Does that mean it is tainted by GPL and I can't make it Boost?
As an alternative why not make ODBC bindings? This way yo
On Mon, 17 Oct 2011 11:37:43 -0400, Kagamin wrote:
Steven Schveighoffer Wrote:
That is good! Since 2007, huh I'm surprised I could find no
discussion on this
http://krow.livejournal.com/684068.html?thread=2674468#t2674468
Yes, I saw that. But that is hardly "discussion in the commu
On 17.10.2011 17:26, Piotr Szturmaj wrote:
You probably meant me. If we create MySQL client without using C
bindings then we would have one of the fastest bindings at all. It may
attract some people who write web apps to D. The same applies to
PostgreSQL for which I wrote client without using a
On Mon, 17 Oct 2011 11:40:44 -0400, Kagamin wrote:
> Steve Teale Wrote:
>
>> Header files may be an issue with the database implementations. For
>> example my mysql.d is a straight translation of mysql.h (and a couple
>> of others). Does that mean it is tainted by GPL and I can't make it
>> Boost
simendsjo wrote:
On 17.10.2011 17:26, Piotr Szturmaj wrote:
You probably meant me. If we create MySQL client without using C
bindings then we would have one of the fastest bindings at all. It may
attract some people who write web apps to D. The same applies to
PostgreSQL for which I wrote clien
On 17.10.2011 17:55, Piotr Szturmaj wrote:
simendsjo wrote:
On 17.10.2011 17:26, Piotr Szturmaj wrote:
You probably meant me. If we create MySQL client without using C
bindings then we would have one of the fastest bindings at all. It may
attract some people who write web apps to D. The same a
simendsjo wrote:
On 17.10.2011 17:55, Piotr Szturmaj wrote:
simendsjo wrote:
On 17.10.2011 17:26, Piotr Szturmaj wrote:
You probably meant me. If we create MySQL client without using C
bindings then we would have one of the fastest bindings at all. It may
attract some people who write web app
> PostgreSQL's protocol is stable since 2003, but MySQL's is not very
> friendly indeed. Phobos might follow opportunistic path and support
> direct access with recent MySQL versions and C wrapper for older ones.
But it looks like the C wrapper approach for MySQL won't fly for Phobos
because of t
On 17.10.2011 18:16, Piotr Szturmaj wrote:
simendsjo wrote:
On 17.10.2011 17:55, Piotr Szturmaj wrote:
simendsjo wrote:
On 17.10.2011 17:26, Piotr Szturmaj wrote:
You probably meant me. If we create MySQL client without using C
bindings then we would have one of the fastest bindings at all.
>
> As an alternative why not make ODBC bindings? This way you'll be able to
> use virtually any database. ODBC is the most important database binding.
I can't find any definitive source for the ODBC header files. I've seen
various versions that seem to make conflicting copyright claims or to
h
Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale
:
PostgreSQL's protocol is stable since 2003, but MySQL's is not very
friendly indeed. Phobos might follow opportunistic path and support
direct access with recent MySQL versions and C wrapper for older ones.
But it looks like the C wrapper appro
On Monday, October 17, 2011 09:38 Steve Teale wrote:
> > PostgreSQL's protocol is stable since 2003, but MySQL's is not very
> > friendly indeed. Phobos might follow opportunistic path and support
> > direct access with recent MySQL versions and C wrapper for older ones.
>
> But it looks like the
Am 17.10.2011, 19:46 Uhr, schrieb Marco Leise :
Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale
:
PostgreSQL's protocol is stable since 2003, but MySQL's is not very
friendly indeed. Phobos might follow opportunistic path and support
direct access with recent MySQL versions and C wrapper for o
On 17.10.2011 19:46, Marco Leise wrote:
Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale
:
PostgreSQL's protocol is stable since 2003, but MySQL's is not very
friendly indeed. Phobos might follow opportunistic path and support
direct access with recent MySQL versions and C wrapper for older ones.
On 2011-10-17 19:55, Jonathan M Davis wrote:
On Monday, October 17, 2011 09:38 Steve Teale wrote:
PostgreSQL's protocol is stable since 2003, but MySQL's is not very
friendly indeed. Phobos might follow opportunistic path and support
direct access with recent MySQL versions and C wrapper for old
On Monday, October 17, 2011 11:07 simendsjo wrote:
> On 17.10.2011 19:46, Marco Leise wrote:
> > Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale
> >
> > :
> >>> PostgreSQL's protocol is stable since 2003, but MySQL's is not very
> >>> friendly indeed. Phobos might follow opportunistic path and suppo
On 2011-10-17 20:07, simendsjo wrote:
On 17.10.2011 19:46, Marco Leise wrote:
Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale
:
PostgreSQL's protocol is stable since 2003, but MySQL's is not very
friendly indeed. Phobos might follow opportunistic path and support
direct access with recent MySQL
On Fri, 14 Oct 2011 14:23:32 +, Steve Teale wrote:
> OK, for what it's worth, the compiler generated documentation (well,
> more or less) for my mysqlD effort is now on my web site.
>
> http://britseyeview.com/software/mysqld/
Updated this so it now also has database and table listings, colu
On 17.10.2011 20:24, Jonathan M Davis wrote:
There is code in druntime and Phobos which special-cases for Windows 98 and
earlier (e.g. std.file using the A functions instead of the W functions if the
version of Windows that you're running on is too old to have the W functions).
Now, personally, I
On Monday, October 17, 2011 11:37 simendsjo wrote:
> On 17.10.2011 20:24, Jonathan M Davis wrote:
> > There is code in druntime and Phobos which special-cases for Windows 98
> > and earlier (e.g. std.file using the A functions instead of the W
> > functions if the version of Windows that you're run
It looks as if it is not a big deal to use the MySQL protocol rather than
the client library. I can now log in that way, so the rest should follow,
and I am working on the changeover. The current MySQL protocol has been
around since version 4.1.
Given that Piotr has, I think, already done the s
Steve Teale wrote:
It looks as if it is not a big deal to use the MySQL protocol rather than
the client library. I can now log in that way, so the rest should follow,
and I am working on the changeover. The current MySQL protocol has been
around since version 4.1.
Good to hear that! One note th
>
> Good to hear that! One note though. MySQL protocol has two row encoding
> modes, text or binary. Please consider using the latter for better
> performance.
>
>
Certainly - it would be pretty inefficient given the implementation
intended to use text.
Steve
Steve Teale Wrote:
> Given that Piotr has, I think, already done the same work at protocol
> level for Postgres, that SQLite is public domain, and that a similar API
> can be done with ODBC, we should be able to cover a fair range of systems
> without falling foul of GPL.
It is said ODBC is co
> Steve Teale wrote:
>> It looks as if it is not a big deal to use the MySQL protocol rather
>> than the client library. I can now log in that way, so the rest should
>> follow, and I am working on the changeover. The current MySQL protocol
>> has been around since version 4.1.
>
Unfortunately I a
Steve Teale wrote:
Steve Teale wrote:
It looks as if it is not a big deal to use the MySQL protocol rather
than the client library. I can now log in that way, so the rest should
follow, and I am working on the changeover. The current MySQL protocol
has been around since version 4.1.
Unfortuna
On Thu, 20 Oct 2011 13:41:05 -0400, Piotr Szturmaj
wrote:
Steve Teale wrote:
Steve Teale wrote:
It looks as if it is not a big deal to use the MySQL protocol rather
than the client library. I can now log in that way, so the rest should
follow, and I am working on the changeover. The current
>
> Please be cautious about reading GPL'd source code to understand the
> protocol. It's possible to be in violation of the license based on
> this.
>
> It generally takes two people to do this correctly, one to read and
> understand the original code, and one to implement the new version based
Kagamin Wrote:
> Steve Teale Wrote:
>
> > Given that Piotr has, I think, already done the same work at protocol
> > level for Postgres, that SQLite is public domain, and that a similar API
> > can be done with ODBC, we should be able to cover a fair range of systems
> > without falling foul of
Steven Schveighoffer Wrote:
> Please be cautious about reading GPL'd source code to understand the
> protocol. It's possible to be in violation of the license based on this.
As long as he doesn't copy the code, there's no violation. He can even organize
code better (or worse), e.g. use OOP, t
On Thu, 20 Oct 2011 15:56:24 -0400, Kagamin wrote:
Steven Schveighoffer Wrote:
Please be cautious about reading GPL'd source code to understand the
protocol. It's possible to be in violation of the license based on
this.
As long as he doesn't copy the code, there's no violation. He can e
> If it comes down to it, someone can volunteer to help debug the code by
> comparing it to the GPL'd library in areas where the spec seems to be
> incorrect and completing the spec. I can help with this if you really
> need it, I'd love to see native D support for MySQL, as it's my DB of
> choice
Just a quick progress report.
Since it was clear that my original ideas for a MySQL D interface were
not going to make it into Phobos at least because of license issues, I
have been investigating the use of the published MySQL client/server
protocol (this was expressly removed from GPL, if it c
As in the initial discussions on database interfaces, I am still of
the view that such support should be provided at three levels. I also
suggest that we adopt a proposal that was hinted at in the initial
discussions, and think in the longer term of having components that
are devoted to SQL, and th
Steve Teale Wrote:
> So one question is where should such implementations go?
github?
> Another questions relates to the definition of interfaces at module
> level. We have interfaces that go hand-in-hand with classes built in
> to the language. But if I wanted to say that two sql interface modu
On Fri, 25 Nov 2011 12:53:36 -0500, Kagamin wrote:
> Steve Teale Wrote:
>
>> So one question is where should such implementations go?
>
> github?
Well, probably yes, but that sounds a bit like "if you build it they will
come", which doesn't always work.
>
>> Another questions relates to the d
Steve Teale Wrote:
> > It can be done using concepts: a template which instantiates to a set of
> > static asserts about what you want.
>
> Is that what we do with Ranges?
Range concepts are boolean. There was a discussion on how to get detailed
diagnostic if concept is not met, so that one wou
On 10/9/2011 2:50 AM, Jacob Carlborg wrote:
On 2011-10-08 19:00, Andrei Alexandrescu wrote:
1. If we build a D wrapper for ODBC, then we allow people to write code
for any database that has an ODBC driver. This, assuming we commit to
ODBC as D's standard database interface, would complete the pr
On Friday, December 02, 2011 16:02:59 Hans Uhlig wrote:
> On 10/9/2011 2:50 AM, Jacob Carlborg wrote:
> > On 2011-10-08 19:00, Andrei Alexandrescu wrote:
> >> 1. If we build a D wrapper for ODBC, then we allow people to write
> >> code
> >> for any database that has an ODBC driver. This, assuming w
Le 03/12/2011 01:02, Hans Uhlig a écrit :
>
> One thing I notice is everyone seems to only be Targeting Relational
> Databases. Any plans to support Flat, Object, Key Value, Hierarchical,
> or Network Model systems? It would be nice to have at least
> specification support for systems like membase
> One thing I notice is everyone seems to only be Targeting Relational
> Databases. Any plans to support Flat, Object, Key Value, Hierarchical,
> or Network Model systems? It would be nice to have at least
> specification support for systems like membase(memcache), hbase,
> vertica, csv files, and
Am 03.12.2011, 13:07 Uhr, schrieb Dejan Lekic :
One thing I notice is everyone seems to only be Targeting Relational
Databases. Any plans to support Flat, Object, Key Value, Hierarchical,
or Network Model systems? It would be nice to have at least
specification support for systems like membase
I'm willing to try and contribute as best I can.
Steve Teale wrote:
> I use this title at Andrei's suggestion, and repeat his idea that it be
> used as a prefix for discussions as we navigate toward a design. Unless
> there is resistance to the idea, I will on the job of implementing
> whatever w
Andrei,
I had a go at odbcd at about the time I first started on mysqld. I must dig it
out and
get it up to the same state so that I understand ODBC again
But basically from what you're saying, all we need is the ODBC header files
translated into D. There appear to be driver managers and plenty
On 10/8/11 11:49 AM, Steve Teale wrote:
Andrei,
I had a go at odbcd at about the time I first started on mysqld. I must dig it
out and
get it up to the same state so that I understand ODBC again
But basically from what you're saying, all we need is the ODBC header files
translated into D.
Th
Andrei,
It's not an easy one is it.
I think it has to be #2. If we just did #1 we would probably alienate
the Linux community.
#3 is a recipe for maintenance problems.
It would be nice if the DB specific drivers could be mixed and matched
with whatever we come up with as the standard D interfac
On Saturday, October 08, 2011 06:43:29 Steve Teale wrote:
> I'd also like to get a feel for the magnitude of the task, so I'd like to
> ask what database systems you think should be supported.
sqlite, postgres, and mysql are the ones that come to mind for me, though
outside of a corporate environ
On 10/8/11 8:36 AM, Adam Burton wrote:
I'd also like to get a feel for the magnitude of the task, so I'd like to
ask what database systems you think should be supported.
mysql, postgresql, sqllite are the 3 I am aiming at in my personal
implementation.
I had lunch yesterday with a database exp
On Saturday, October 08, 2011 12:00:37 Andrei Alexandrescu wrote:
> 1. If we build a D wrapper for ODBC, then we allow people to write code
> for any database that has an ODBC driver. This, assuming we commit to
> ODBC as D's standard database interface, would complete the project.
>
> 2. If we wa
Microsoft SQL Server is important to cover too. I'm pretty sure
ODBC works fine for that (there's ODBC bindings for D already,
it's part of the Windows headers) and I wrote a little something
for my database.d, but I haven't actually tested it yet!
(The project I work on for SQL server has a lot o
The database API I wrote ages ago is built on ODBC and you're welcome to a copy
if it would help. At the time (admittedly 15 years ago) the docs for ODBC were
incomplete and wrong in places, so a reference can be handy.
Sent from my iPhone
On Oct 8, 2011, at 9:49 AM, Steve Teale wrote:
> And
Jonathan M Davis wrote:
> On Saturday, October 08, 2011 12:00:37 Andrei Alexandrescu wrote:
>> 1. If we build a D wrapper for ODBC, then we allow people to write code
>> for any database that has an ODBC driver. This, assuming we commit to
>> ODBC as D's standard database interface, would complete
Steve Teale Wrote:
> I use this title at Andrei's suggestion, and repeat his idea that it be used
> as a prefix for discussions as we navigate toward a design. Unless there is
> resistance to the idea, I will on the job of implementing whatever we decide
> is appropriate. I am retired, and have th
On 2011-10-08 19:00, Andrei Alexandrescu wrote:
1. If we build a D wrapper for ODBC, then we allow people to write code
for any database that has an ODBC driver. This, assuming we commit to
ODBC as D's standard database interface, would complete the project.
2. If we want to go the route of "one
On 2011-10-08 23:11, Adam D. Ruppe wrote:
Microsoft SQL Server is important to cover too. I'm pretty sure
ODBC works fine for that (there's ODBC bindings for D already,
it's part of the Windows headers) and I wrote a little something
for my database.d, but I haven't actually tested it yet!
I ha
On 2011-10-08 23:12, Jonathan M Davis wrote:
On Saturday, October 08, 2011 12:00:37 Andrei Alexandrescu wrote:
1. If we build a D wrapper for ODBC, then we allow people to write code
for any database that has an ODBC driver. This, assuming we commit to
ODBC as D's standard database interface, wo
Am 08.10.2011 23:11, schrieb Adam D. Ruppe:
Microsoft SQL Server is important to cover too.
Yeah, it's probably pretty widely used in the Windows world so it should
be supported.
And Oracle should probably be supported as well.
But if we have a generic DB API support for these can be added l
Steve Teale wrote:
I use this title at Andrei's suggestion, and repeat his idea that it be used
as a prefix for discussions as we navigate toward a design. Unless there is
resistance to the idea, I will on the job of implementing whatever we decide
is appropriate. I am retired, and have the time
On 10/9/11 7:28 AM, Piotr Szturmaj wrote:
1. I think that we should not design this API using the least common
denominator approach. This is to not limit some databases. For example
PostgreSQL has many great features not available in MySQL. That's why I
started with postgres in my ddb project. I
There was some discussion prior to this thread about the relative virtues
of binding to structs or binding to arrays of Variants. I was thinking
about this, and have experimented with Variants in my trial MySQL
implementation. My conclusions below - do they make sense?
Using Variant to capture
Further question. Should we assume in the first instance that we should
only attempt to accommodate those DBs that are free or have some free
version that may be limited in some way - e.g. the developer version of
MS SQL Server.
Presumably when D reaches the point of being all-conquering, then
Further generic question. (Yes, I am listening to the answers too)
If some underlying databases don't support the features that our chosen
interface requires, do we attempt to synthesize them - presumably at cost
to performance, or do we just throw a compile-time exception that
basically tells
The way I'd do it is:
interface Database {
// support shared functions here, and other stuff useful enough to
// warrant emulation
}
class Postgres : Database {
// implement the interface, of course, but also all other postgres
// specific stuff
}
When you go to use it, if you're happy
Adam Ruppe wrote:
The way I'd do it is:
interface Database {
// support shared functions here, and other stuff useful enough to
// warrant emulation
}
class Postgres : Database {
// implement the interface, of course, but also all other postgres
// specific stuff
}
When you go to
Steve Teale wrote:
To express a personal opinion, then as a first pass we should do
something that is at about the same level as JDBC but without the
concessions to DBs like Postgres that have fancy SQL types.
I disagree. Doing it this way may introduce difficulties or
incompabilities in the f
> We probably should write a page on a wiki describing the API, without
> actually implementing anything. Then anyone involved may contribute to
> its design, so it may evolve into somewhat more thought out API.
I like that idea! Must find out how to put up a wiki.
Steve
Steve Teale wrote:
We probably should write a page on a wiki describing the API, without
actually implementing anything. Then anyone involved may contribute to
its design, so it may evolve into somewhat more thought out API.
I like that idea! Must find out how to put up a wiki.
Or use existin
On 10/9/11 11:54 AM, Adam Ruppe wrote:
The way I'd do it is:
interface Database {
// support shared functions here, and other stuff useful enough to
// warrant emulation
}
class Postgres : Database {
// implement the interface, of course, but also all other postgres
// specific stuf
On 10/9/11 11:15 AM, Steve Teale wrote:
If using variants for a set of out parameters you must have something
equivalent to:
Variant[3] va;
va[0] = cast(byte) 0;
va[1] = 0.0F;
va[2] = cast(char[]) [];
So you have to have exactly the same information at compile time for the
Variant array as you
On 10/9/11 11:40 AM, Steve Teale wrote:
Further generic question. (Yes, I am listening to the answers too)
If some underlying databases don't support the features that our chosen
interface requires, do we attempt to synthesize them - presumably at cost
to performance, or do we just throw a compi
On 2011-10-09 18:54, Adam Ruppe wrote:
The way I'd do it is:
interface Database {
// support shared functions here, and other stuff useful enough to
// warrant emulation
}
class Postgres : Database {
// implement the interface, of course, but also all other postgres
// specific stuf
On 10/09/11 13:22, Andrei Alexandrescu wrote:
On 10/9/11 11:40 AM, Steve Teale wrote:
Further generic question. (Yes, I am listening to the answers too)
If some underlying databases don't support the features that our chosen
interface requires, do we attempt to synthesize them - presumably at c
On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
1. I think that we should not design this API using the least common denominator
approach. This is to not limit some databases. For example PostgreSQL has many
great features not available in MySQL. That's why I started with postgres in my
ddb project.
On 10/7/2011 11:43 PM, Steve Teale wrote:
I use this title at Andrei's suggestion, and repeat his idea that it be used
as a prefix for discussions as we navigate toward a design. Unless there is
resistance to the idea, I will on the job of implementing whatever we decide
is appropriate. I am reti
On 10/9/11 5:31 PM, Walter Bright wrote:
On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
1. I think that we should not design this API using the least common
denominator
approach. This is to not limit some databases. For example PostgreSQL
has many
great features not available in MySQL. That's why I
On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote:
> On 10/9/11 5:31 PM, Walter Bright wrote:
>> On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
>>> 1. I think that we should not design this API using the least common
>>> denominator
>>> approach. This is to not limit some databases. For example P
On Sunday, October 09, 2011 16:31:35 Sean Kelly wrote:
> On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote:
> > On 10/9/11 5:31 PM, Walter Bright wrote:
> >> On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
> >>> 1. I think that we should not design this API using the least common
> >>> denominator
On 10/9/11 6:31 PM, Sean Kelly wrote:
On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote:
On 10/9/11 5:31 PM, Walter Bright wrote:
On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
1. I think that we should not design this API using the least common
denominator
approach. This is to not limit som
> I'd like to suggest that, as a first step, simple translations of the C
> header files for the various databases be added to etc.c. That'll at
> least enable people who need to use a database now to get started.
Walter,
I'm sure they're already out there waiting. I have MySQL. Any offers for
P
On 2011-10-10 00:31, Walter Bright wrote:
On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
1. I think that we should not design this API using the least common
denominator
approach. This is to not limit some databases. For example PostgreSQL
has many
great features not available in MySQL. That's why
On 2011-10-10 06:54, Steve Teale wrote:
I'd like to suggest that, as a first step, simple translations of the C
header files for the various databases be added to etc.c. That'll at
least enable people who need to use a database now to get started.
Walter,
I'm sure they're already out there wai
On Sun, 09 Oct 2011 20:31:35 -0300, Sean Kelly
wrote:
On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote:
On 10/9/11 5:31 PM, Walter Bright wrote:
On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
1. I think that we should not design this API using the least common
denominator
approach. This
On Sat, 08 Oct 2011 17:19:02 +0100, Andrei Alexandrescu
wrote:
On 10/8/11 8:36 AM, Adam Burton wrote:
I'd also like to get a feel for the magnitude of the task, so I'd like
to
ask what database systems you think should be supported.
mysql, postgresql, sqllite are the 3 I am aiming at in m
>
> You can glean all needed information from the resultset after having
> issued the query.
>
>> It's probably true to say that the syntax/semantics of the interface
>> will suck slightly more in the Variant case than in the struct case.
>
> That's a given. The suckiness won't come, however, in
Here's a sketch of an interface. This is based on my experiments with
MySQL, and as such it is probably mid-level, and not a top level covers-
all interface.
Hopefully it will create a number of discussion points.
// Can interfaces include template functions???
interface SQLDBConnection
{
@pr
Surprising. I read a research paper about a proposed language just a few months
ago. I wonder if this is by the same guys.
Sent from my iPhone
On Oct 10, 2011, at 12:05 AM, "Roald Ribe" wrote:
> On Sun, 09 Oct 2011 20:31:35 -0300, Sean Kelly wrote:
>
>> On Oct 9, 2011, at 3:56 PM, Andrei Al
I've just been looking at the documentation for the PostgreSQL C api. Wow!
It is so different from MySQL, and so clean. No out parameters from
queries. That one is not going to be a problem.
Steve
On 10/10/11 7:01 AM, Steve Teale wrote:
You can glean all needed information from the resultset after having
issued the query.
It's probably true to say that the syntax/semantics of the interface
will suck slightly more in the Variant case than in the struct case.
That's a given. The suckine
1 - 100 of 273 matches
Mail list logo
