Thanks for laying this out, this really helps me respond to at least some of
your concerns.
Firstly, I’d like to clarify that my position is only a personal one - I don’t
expect the project, or you, to necessarily have the same viewpoint. But it
does mean that I don’t have to engage too
> Anyway, I think we’ve been arguing very unnecessarily about this
ideological
> point, given that I’ve already suggested a toggle to permit users to
continue
> with present-day semantics should they choose. Surely this resolves your
> concerns, unless you think this is intractable?
Not really
To clarify send an empty email (no subject or body) to
dev-unsubscr...@cassandra.apache.org
You will then get a confirmation email with a link. Click that.
Dinesh
On Tuesday, November 20, 2018, 6:20:34 PM GMT+2, Michael Shuler
wrote:
On 11/20/18 10:15 AM, Versátil wrote:
>
> I
This was a terribly unclear email, sorry. I was just trying to find new and
interesting ways to say the same thing (that we should form our goal state from
first principles only).
Anyway, I think we’ve been arguing very unnecessarily about this ideological
point, given that I’ve already
This is why I said the decision is ideological. We fundamentally disagree with
each other, on points of principle.
This also feels like it’s becoming antagonistic, perhaps through
misinterpreting each other, which was far from my intent. So I will limit my
reply to the only point of
On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith
wrote:
> We’re not presently voting*; we’re only discussing, whether we should base
> our behaviour on a widely agreed upon standard.
>
Well, you *explicitely* asked if people though we should do a vote, and I
responded to that part. Let's
Well, to expand my glib statement, standards exist for at least two reasons
that I endorse in this case:
1) They are well thought out, with a great deal more consideration than we have
time to give to a problem
2) They are widely implemented, understood and used. So our users and
developers
Sorry, following a standard for the sake of following a standard does not
make sense to me.
On Thu, Nov 22, 2018 at 12:33 PM Benedict Elliott Smith
wrote:
> Yes.
>
> > On 22 Nov 2018, at 11:32, Benjamin Lerer
> wrote:
> >
> > Then I would be interested in knowing `where we should be`. If the
Yes.
> On 22 Nov 2018, at 11:32, Benjamin Lerer wrote:
>
> Then I would be interested in knowing `where we should be`. If the answer
> is `ANSI SQL92` then my question is: Why? Simply for the sake of following
> a standard?
>
>
> On Thu, Nov 22, 2018 at 12:19 PM Benedict Elliott Smith
Then I would be interested in knowing `where we should be`. If the answer
is `ANSI SQL92` then my question is: Why? Simply for the sake of following
a standard?
On Thu, Nov 22, 2018 at 12:19 PM Benedict Elliott Smith
wrote:
> As I say, for me this is explicitly unhelpful, so I have no
As I say, for me this is explicitly unhelpful, so I have no intention of
producing it (though, of course, I cannot prevent you from producing it)
For me, the correct approach is to decide where we should be, and then figure
out how to get there. Where we are has no bearing on where we should
I would also like to see an analysis of what being ANSI SQL 92 compliant
means in term of change of behavior (for arithmetics and *any features we
have already released*).
Simply because without it, I find the decision pretty hard to make.
On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith
We’re not presently voting*; we’re only discussing, whether we should base our
behaviour on a widely agreed upon standard.
I think perhaps the nub of our disagreement is that, in my view, this is the
only relevant fact to decide. There is no data to base this decision upon.
It’s axiomatic,
I'm not saying "let's not do this no matter what and ever fix technical
debt", nor am I fearing decision.
But I *do* think decisions, technical ones at least, should be fact and
data driven. And I'm not even sure why we're talking of having a vote here.
The Apache Way is *not* meant to be
I can’t agree more. We should be able to make changes in a manner that
improves the DB In the long term, rather than live with the technical debt
of arbitrary decisions made by a handful of people.
I also agree that putting a knob in place to let people migrate over is a
reasonable decision.
Jon
The goal is simply to agree on a set of well-defined principles for how we
should behave. If we don’t like the implications that arise, we’ll have
another vote? A democracy cannot bind itself, so I never understood this fear
of a decision.
A database also has a thousand toggles. If we
On Tue, Nov 20, 2018 at 5:02 PM Benedict Elliott Smith
wrote:
> FWIW, my meaning of arithmetic in this context extends to any features we
> have already released (such as aggregates, and perhaps other built-in
> functions) that operate on the same domain. We should be consistent, after
> all.
>
On 11/20/18 10:15 AM, Versátil wrote:
>
> I already requested as you said and it did not help. And I NEVER asked to
> enter into this discussion. Please request to withdraw my email
| | | | | | | | | |
\/\/\/\/\/\/\/\/\/\/
>
>
2018 14:12
Para: dev@cassandra.apache.org
Cc: dev-unsubscribe-versatil=versatilengenharia.com...@cassandra.apache.org
Assunto: Re: RES: Implicit Casts for Arithmetic Operators
On 11/20/18 9:53 AM, Versátil wrote:
>
> PLEASE TAKE MY EMAIL FROM THIS SHIT !!
FYI, mailing list subscri
On 11/20/18 9:53 AM, Versátil wrote:
>
> PLEASE TAKE MY EMAIL FROM THIS SHIT !!
FYI, mailing list subscriptions (and unsubscriptions) are self-serve. In
general, you subscribed yourself, so you are responsible to unsubscribe.
The email address to do so is appended to every plain text message to
FWIW, my meaning of arithmetic in this context extends to any features we have
already released (such as aggregates, and perhaps other built-in functions)
that operate on the same domain. We should be consistent, after all.
Whether or not we need to revisit any existing functionality we can
PLEASE TAKE MY EMAIL FROM THIS SHIT !!
-Mensagem original-
De: Michael Burman [mailto:y...@iki.fi]
Enviada em: terça-feira, 20 de novembro de 2018 13:51
Para: dev@cassandra.apache.org
Assunto: Re: Implicit Casts for Arithmetic Operators
Yep, that's a good approach.
- Micke
On Tue
Yep, that's a good approach.
- Micke
On Tue, Nov 20, 2018 at 5:12 PM Ariel Weisberg wrote:
> Hi,
>
> +1
>
> This is a public API so we will be much better off if we get it right the
> first time.
>
> Ariel
>
> > On Nov 16, 2018, at 10:36 AM, Jonathan Haddad wrote:
> >
> > Sounds good to me.
Sounds good to me.
On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith
wrote:
> So, this thread somewhat petered out.
>
> There are still a number of unresolved issues, but to make progress I
> wonder if it would first be helpful to have a vote on ensuring we are ANSI
> SQL 92 compliant for
So, this thread somewhat petered out.
There are still a number of unresolved issues, but to make progress I wonder if
it would first be helpful to have a vote on ensuring we are ANSI SQL 92
compliant for our arithmetic? This seems like a sensible baseline, since we
will hopefully minimise
I think we do, implicitly, support precision and scale - only dynamically. The
precision and scale are defined by the value on insertion, i.e. those necessary
to represent it exactly. During arithmetic operations we currently truncate to
decimal128, but we can (and probably should) change
Hi,
>From reading the spec. Precision is always implementation defined. The spec
>specifies scale in several cases, but never precision for any type or
>operation (addition/subtraction, multiplication, division).
So we don't implement anything remotely approaching precision and scale in CQL
If it’s in the SQL spec, I’m fairly convinced. Thanks for digging this out
(and Mike for getting some empirical examples).
We still have to decide on the approximate data type to return; right now, we
have float+bigint=double, but float+int=float. I think this is fairly
inconsistent, and
Hi,
I agree with what's been said about expectations regarding expressions
involving floating point numbers. I think that if one of the inputs is
approximate then the result should be approximate.
One thing we could look at for inspiration is the SQL spec. Not to follow
dogmatically
Hi,
I'm not sure if I would prefer the Postgres way of doing things, which is
returning just about any type depending on the order of operators.
Considering it actually mentions in the docs that using numeric/decimal is
slow and also multiple times that floating points are inexact. So doing
some
As far as I can tell we reached a relatively strong consensus that we should
implement lossless casts by default? Does anyone have anything more to add?
Looking at the emails, everyone who participated and expressed a preference was
in favour of the “Postgres approach” of upcasting to decimal
I think you're conflating two things here. There's the loss resulting from
using some operators, and loss involved in casting. Dividing an integer by
another integer to obtain an integer result can result in loss, but there's
no implicit casting there and no loss due to casting. Casting an
Hi,
I would like to try to clarify things a bit to help people to understand
the true complexity of the problem.
The *float *and *double *types are inexact numeric types. Not only at the
operation level.
If you insert 676543.21 in a *float* column and then read it, you will
realize that the
Thanks for starting this discussion. I’m definitely in the lossless camp. I’m
curious of the performance impact of choosing lossless vs lossy.
Dinesh
> On Oct 2, 2018, at 10:54 AM, Benedict Elliott Smith
> wrote:
>
> I agree, in broad strokes at least. Interested to hear others’ positions.
+1 on Postgres approach. In the last 5 years I’ve seen people move from Oracle
and SQL server to some variant of Cassandra or Postgres and other new tech is
also more likely to support Postgres (Cockroach..)
I don’t care either way. It really depends on what you are storing.
Rahul Singh
Chief
Thanks for bringing this up, it definitely needs to be discussed.
Last surprise is difficult here, since all major databases have their own
way of doing things and people will just assume that their way is the right
way. On that note, some people will be surprised no matter what we do.
I'd
I agree, in broad strokes at least. Interested to hear others’ positions.
> On 2 Oct 2018, at 16:44, Ariel Weisberg wrote:
>
> Hi,
>
> I think overflow and the role of widening conversions are pretty linked so
> I'll continue to inject that into this discussion. Also overflow is much
>
Hi,
I think overflow and the role of widening conversions are pretty linked so I'll
continue to inject that into this discussion. Also overflow is much worse since
most applications won't be impacted by a loss of precision when an expression
involves an int and float, but will care quite a bit
This (overflow) is an excellent point, but this also affects aggregations which
were introduced a long time ago. They already inherit Java semantics for all
of the relevant types (silent wrap around). We probably want to be consistent,
meaning either changing aggregations (which incurs a cost
Hi,
I think we should decide based on what is least surprising as you mention, but
isn't overridden by some other concern.
It seems to me the priorities are
* Correctness
* Performance
* User visible complexity
* Developer visible complexity
Defaulting to silent implicit data loss is not
CASSANDRA-11935 introduced arithmetic operators, and alongside these came
implicit casts for their operands. There is a semantic decision to be made,
and I think the project would do well to explicitly raise this kind of question
for wider input before release, since the project is bound by
41 matches
Mail list logo
