Re: Procedure for feature requests?

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Procedure for feature requests?
Date: 2009-10-03 23:47:52
Message-ID: 20091003234752.GH5407@samason.me.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Oct 03, 2009 at 04:14:21PM -0400, Tom Lane wrote:
> Sam Mason <sam(at)samason(dot)me(dot)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/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sam Mason 2009-10-04 00:13:47 Re: Embarassing GROUP question
Previous Message Corey Tisdale 2009-10-03 23:12:20 Re: Embarassing GROUP question