Tarantool discussions archive
 help / color / mirror / Atom feed
From: Peter Gulutzan <pgulutzan@ocelot.ca>
To: Imeev Mergen <imeevma@tarantool.org>,
	tarantool-discussions@dev.tarantool.org, kostja.osipov@gmail.com,
	korablev@tarantool.org, alexander.turenko@tarantool.org,
	v.shpilevoy@tarantool.org, kyukhin@tarantool.org,
	tsafin@tarantool.org
Subject: Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT
Date: Thu, 30 Apr 2020 10:04:37 -0600
Message-ID: <3baee836-8404-bfaf-1c3a-353a379861d0@ocelot.ca> (raw)
In-Reply-To: <37b646d1-39a3-f39a-c436-f315fe1359a0@tarantool.org>

Hi,

On 2020-04-30 9:10 a.m., Imeev Mergen wrote:
 > Hi,
 >
 > On 4/30/20 5:40 PM, Peter Gulutzan wrote:
 >> Hi,
 >>
 >> Going back to your original question:
 >>
 >> On 2020-04-30 6:04 a.m., Imeev Mergen wrote:
 >> > Hi! Here we go again. Last time we have not come to a colclusion.
 >> >
 >> > So, I suggest these rules for implicit cast for ASSIGNMENT:
 >> > 1) Any value can be implicitly cast to ANY type.
 >> This is not supported in SQL yet, I have expected that
 >> casting a scalar value to ANY would be like casting to SCALAR.
 > True.
 >
 >> > 2) Any scalar values ​​can be implicitly cast to SCALAR type.
 >> I am not sure what this means.
 >> TYPEOF(CAST(1 AS SCALAR)) is not 'scalar', it is 'integer'.
 >> That is, we allow the syntax for an explicit cast, but do nothing.
 >> So, if all you are saying is that
 >> "we allow implicit cast, but do nothing"
 >> then there is no reason to object, there is no behaviour change.
 > No, I plan to fix it. I already have a fix, and I plan to push it
 > among the patches for this problem.
 >

I didn't expect that.
Why is the current behaviour bad?

 >> > 3) Values ​​of numeric types can be implicitly cast to other numeric
 >> > types.
 >> I believe this but K. Yukhin decided to close issue#4216.
 >> > 4) Implicit casting is prohibited, except as described above.
 >> Yes, "here we go again".
 >> My opinion is unchanged:
 >> Implicit cast of string to number was a mistake.

So far, nobody has objected to your statement
"Implicit casting is prohibited, except as described above."
or to my statement
"Implicit cast of string to number was a mistake."
Therefore
INSERT INTO t (integer_column) VALUES ('1');
will be illegal.
This is a change in documented behaviour.
Should there be a note about deprecation in the manual?

 >> All comparison of values of different data types should be legal.
 > Not sure if we should discuss comparison here, however, do you
 > mean that we should allow comparison of values ​​of different types
 > without implicit casting? Using scalar rules?
 >

Yes. And maybe you sympathize, if you want to fix issue#4783.
But you are right, this is not the topic to be discussed now.

 >> Of course, assignment may cause an out-of-range error.
 >> >
 >> >
 >> > I think that the rules for implicit casting when assigning value
 >> > of numeric type must be the same as in C.
 >> >
 >> You mean there should be truncation not rounding?
 > Yes.
 >
 >> > On 2/13/20 5:25 PM, Mergen Imeev wrote:
 >> >> Hi all,
 >> >> I would like to discuss the second issue of casts in SQL. I mean
 >> >> implicit casting for ASSIGNMENT.
 >> >>
 >> >> For now, I suggest avoiding questions about SCALAR, as the
 >> >> discussion is already in progress.
 >> >>
 >> >> So, I suggest removing the current implicit casts. We can
 >> >> reimplement implicit casts in accordance with ANSI in issue #3836.
 >> >> But since priority of #3836 is low, this is most likely not going
 >> >> to happen for some time.
 >> >>
 >> >> At the moment, I see two ways to remove implicit casts:
 >> >> 1) Disable all implicit casts, except casts for numeric values.
 >> >> These casts will become UDCF later.
 >> >> 2) Disable all implicit casts. Assignment in Tarantool-SQL will
 >> >> work the same as in noSQL Tarantool.
 >> >>
 >> >> What do you think about this?
 >> >>
 >> For this earlier email, didn't everyone respond already?
 > I'd like to get more definite answers.
 >
 >>
 >> Peter Gulutzan

Peter Gulutzan

  reply	other threads:[~2020-04-30 16:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13 14:25 Mergen Imeev
2020-02-13 14:40 ` Konstantin Osipov
2020-02-13 22:20 ` Peter Gulutzan
2020-04-30 12:04 ` Imeev Mergen
2020-04-30 12:35   ` Konstantin Osipov
2020-04-30 12:56     ` Imeev Mergen
2020-04-30 13:09       ` Konstantin Osipov
2020-04-30 13:12         ` Imeev Mergen
2020-04-30 14:04           ` Konstantin Osipov
2020-04-30 14:15             ` Peter Gulutzan
2020-04-30 14:28               ` Konstantin Osipov
2020-04-30 14:40   ` Peter Gulutzan
2020-04-30 15:10     ` Imeev Mergen
2020-04-30 16:04       ` Peter Gulutzan [this message]
2020-05-07 16:14         ` Peter Gulutzan
2020-05-08 11:57           ` Kirill Yukhin
2020-04-30 22:52       ` [Tarantool-discussions] Descriptive SQL Style Guide Peter Gulutzan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3baee836-8404-bfaf-1c3a-353a379861d0@ocelot.ca \
    --to=pgulutzan@ocelot.ca \
    --cc=alexander.turenko@tarantool.org \
    --cc=imeevma@tarantool.org \
    --cc=korablev@tarantool.org \
    --cc=kostja.osipov@gmail.com \
    --cc=kyukhin@tarantool.org \
    --cc=tarantool-discussions@dev.tarantool.org \
    --cc=tsafin@tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Tarantool discussions archive

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lists.tarantool.org/tarantool-discussions/0 tarantool-discussions/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 tarantool-discussions tarantool-discussions/ https://lists.tarantool.org/tarantool-discussions \
		tarantool-discussions@dev.tarantool.org.
	public-inbox-index tarantool-discussions

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git