Re: RfD: more powerful "any" types

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RfD: more powerful "any" types
Date: 2009-09-10 20:43:47
Message-ID: 162867790909101343nb09f96ei450b4f9a04a3eda4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/9/10 Dimitri Fontaine <dfontaine(at)hi-media(dot)com>:
> Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
>>> > 5. Various syntactic sugar to substitute for anyelement.  (Not in favor
>>> > of this myself, it seems to just complicate matters.)
>>>
>>> I agree; I don't think this solves any real problem.
>>
>> agreed, it does not solve the underlying problem, just may make it
>> easier to understand and remember for users.
>
> Well, depends. I'm not convinced that abusing typmods for solving this
> is a good idea, but it's just feeling. Having the same syntax covers
> different semantics depending on the context is like interpreting data
> in a column in different ways, and is on Josh's list of things to do if
> you wanna wreck your database.
>
>> f(a anyelement1, b anyelement2) and f(a anyelement2, b anyelement1)
>>
>> seem to be different but actually are not, so we will need to handle
>> multiple anyelementN types separately from ordinary types.
>
> Here for example you see that typmod on anyelement would mean something
> entirely different from typmod on, say, numeric.
>
> This looks like a ugly hack.
>
>> ANY [TYPE] and SAME AS [TYPE OF] are syntactic sugar indeed, but they
>> are much more SQL-like than needing to write "any" or anyelement(n) as
>> argument type or return type
>

it's less confusing, than abstract types. And really nicer.

SQL have to be readable for non hard developers too. And this is
readable. Much more than anylement(1) or anyelement(n).

> Not only it looks SQL'ish, but it'll be easier to document and use. And
> it won't taint typmods, which still need a refactor to better handle
> PostGIS needs, btw...
>
>
> Now there's still the issue of having first class functions: that means
> we'd be able to store them, have anonymous (lambda) functions (see the
> DO command discussion), higher order function, and open the road to
> generic function support. All that jazz is being pushed back with the
> very natural counter argument: what good is there for having this in
> your SQL database?
>
> So for people on the list who really want to push towards those things,
> I suppose providing realistic use cases (how it would simplify this hack
> you're maintaining in production) would allow for better exchanges :)

I am fully agree

regards
Pavel

>
> Regards,
> --
> dim
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-09-10 20:48:49 Re: RfD: more powerful "any" types
Previous Message Hannu Krosing 2009-09-10 20:38:25 Re: RfD: more powerful "any" types