Tarantool discussions archive
 help / color / mirror / Atom feed
From: Konstantin Osipov <kostja.osipov@gmail.com>
To: Mergen Imeev <imeevma@tarantool.org>
Cc: tarantool-discussions@dev.tarantool.org
Subject: Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT
Date: Thu, 13 Feb 2020 17:40:00 +0300
Message-ID: <20200213144000.GA32013@atlas> (raw)
In-Reply-To: <20200213142534.GA26443@tarantool.org>

* Mergen Imeev <imeevma@tarantool.org> [20/02/13 17:26]:

I think you suggest introducing a behaviour change between minor
releases without a proper deprecation procedure, which violates
the published release policy.

I also don't see in this email any rationale for it.

Issue 3836 is a feature and has little to do with the default
behaviour which you suggest a change. Tarantool should provide
reasonable, expected and widespread behaviour of implicit cast in
absence of CREATE CAST statement.

CREATE CAST itself is a dangerous feature which is (luckily) not
very widely used. I don't think we should do it at all.

> 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?

Konstantin Osipov, Moscow, Russia

  reply	other threads:[~2020-02-13 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 [this message]
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
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:

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

  git send-email \
    --in-reply-to=20200213144000.GA32013@atlas \
    --to=kostja.osipov@gmail.com \
    --cc=imeevma@tarantool.org \
    --cc=tarantool-discussions@dev.tarantool.org \


* 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 \
	public-inbox-index tarantool-discussions

Example config snippet for mirrors.

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