Re: Procedure for feature requests? - Mailing list pgsql-general

From Sam Mason
Subject Re: Procedure for feature requests?
Date
Msg-id 20091003234752.GH5407@samason.me.uk
Whole thread Raw
In response to Re: Procedure for feature requests?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Sat, Oct 03, 2009 at 04:14:21PM -0400, Tom Lane wrote:
> Sam Mason <sam@samason.me.uk> writes:
> > the decision to officially bless some code as being a cast
> > rather than "just" a function seems very arbitrary
>
> It's useful when the conversion semantics are sufficiently natural that
> you want the conversion to be applied implicitly.

Thanks!  After a big think I've ended up thinking the implicit casts
between the various numeric and date types are a good thing.  They can
cause some confusion and semantic strangeness, but the increase in code
verbosity that results without them normally offsets these costs.

In higher assurance code this balance may tip back the other way, but
databases have more focus on having a sane set of defaults rather than
forcing you to make all the decisions up front.

> I agree that the
> explicit CAST syntax hasn't got very much to recommend it over a
> function call.  That part you can blame on the SQL committee ;-) ...

What more would you want them to do?  Casts that is, the SQL committee
do enough I think!

> the historical PostQUEL syntax for this was exactly a function call,
> and you can still write it that way if you choose.

I have a feeling I'll probably carry on doing that then.  I'm not sure
if I'm ever going to write enough almost overlapping bits of code that
casts would become useful.

--
  Sam  http://samason.me.uk/

pgsql-general by date:

Previous
From: Corey Tisdale
Date:
Subject: Re: Embarassing GROUP question
Next
From: Sam Mason
Date:
Subject: Re: Embarassing GROUP question