From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How hard would it be to support LIKE in return declaration of generic record function calls ? |
Date: | 2012-05-03 16:04:55 |
Message-ID: | CAHyXU0xDM_N-vV-DnDGtmvNkb1W=199qRoc4=S69LY=-S0fk8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 3, 2012 at 10:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Maybe some keyword can help to us. What do you think about new
>> operator TYPE that can returns regtype value and can be used together
>> with polymorphic functions.
>
> Doesn't have any more attraction for me than the proposed LIKE
> extension; that will have the same results and it's at least traceable
> to SQL-standard notations.
no it won't (unless I'm being completely obtuse in addition to being
repetitive): LIKE only works when you treat your function call as a
table expression: FROM func() AS ...
that's fine, but converting-from-json functions will want to be able
to be called anywhere a single value returning function would be
normally called. hstore/populate_record trick allows this, so it's
not apples to apples.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2012-05-03 16:11:47 | Re: remove dead ports? |
Previous Message | Tom Lane | 2012-05-03 16:04:15 | Re: Advisory locks seem rather broken |