Re: minor patch submission: CREATE CAST ... AS EXPLICIT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: minor patch submission: CREATE CAST ... AS EXPLICIT
Date: 2011-05-21 15:38:42
Message-ID: 1642.1305992322@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> Description:
> Add "AS EXPLICIT" to "CREATE CAST"
> This gives a name to the default case of "CREATE CAST", which creates a
> cast which must be explicitely invoked.

I'm not sure this is a good idea. The CREATE CAST syntax is in the SQL
standard, and this isn't it. Now I realize that we've extended that
statement already to cover some functionality that's not in the
standard, but that doesn't mean we should create unnecessarily
nonstandard syntax for cases that are in the standard. If a commercial
vendor did that, wouldn't you castigate them for trying to create vendor
lock-in?

> From a language definition perspective, it is helpful to have a name for
> every case instead of an implicit fallback, without any word to describe
> it. See for instance "CREATE USER CREATEDB/NOCREATEDB" or "CREATE RULE ...
> DO ALSO/INSTEAD" for similar occurences of naming default cases.

If we were working in a green field, I couldn't fault this logic ... but
we are not.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Kupershmidt 2011-05-21 15:59:05 Re: Review: psql include file using relative path
Previous Message Fabien COELHO 2011-05-21 13:46:41 minor patch submission: CREATE CAST ... AS EXPLICIT