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 08:40:42 -0600
Message-ID: <e2d9ebaf-2609-d304-b4dd-debc779af2a8@ocelot.ca> (raw)
In-Reply-To: <36e21524-35d7-9f54-5953-32863df95709@tarantool.org>

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.
 > 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.
 > 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.
All comparison of values of different data types should be legal.
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?
 > 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?

Peter Gulutzan

  parent reply	other threads:[~2020-04-30 14:40 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 [this message]
2020-04-30 15:10     ` Imeev Mergen
2020-04-30 16:04       ` Peter Gulutzan
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=e2d9ebaf-2609-d304-b4dd-debc779af2a8@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