On 12/12/10 00:29, Darren Duncan wrote:
> Petite Abeille wrote:
>> On Dec 11, 2010, at 3:48 PM, Simon Slavin wrote:
>>
>>> Section 21 of the (SQL92) standard.
>> Yes, the notorious information schema:
> Nonsense. An information schema is a *good* thing, and is generally the
> *best*
> tool for
On 13/12/10 01:38, Darren Duncan wrote:
> Darren Duncan wrote:
>> Wols Lists wrote:
>>> Dunno how well that approach translates into a relational engine,
>>> because Pick has several very non-relational quirks (every "row" MUST
>>> have a primary
On 13/12/10 22:44, Darren Duncan wrote:
> I am also very interested in these subjects.
>
> I believe that the relational model can accurately model anything in
> the real world, and that this can be implemented in efficient ways,
> with physical structure taking hints from logical structure.
But
your maths does not describe my reality".
You're talking maths, I'm talking science, we have the potential of a
major conflagration here ...
On 14/12/10 01:29, Darren Duncan wrote:
> Wols Lists wrote:
>> On 13/12/10 22:44, Darren Duncan wrote:
>>> I am also very intereste
are complementary. But said
> programming languages in this case, such as SQL or Muldis D, *are*
> what the DBMS does.
At which point we diverge from the Pick model. SQL and Muldis-D have no
equivalent in the Pick world. (Or they *can* do. Like so much in Pick,
using the database query langu
On 15/12/10 00:18, Darren Duncan wrote:
> Wols Lists wrote:
>>> I think that part of the problem here is that you didn't define what
>>> STORE means. So please clarify with examples as what you see
>>> qualifies as "STORE a list" and what doesn't.
>>
On 15/12/10 02:47, Darren Duncan wrote:
> Wols Lists wrote:
>> On 15/12/10 00:18, Darren Duncan wrote:
>> The point I'm making is that a list doesn't contain any ordering *data*
>> - it's inherent in the fact of a list. A list is an abstract concept. In
>> Pick, I
7 matches
Mail list logo