From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: auxiliary functions for record type |
Date: | 2010-12-13 07:23:59 |
Message-ID: | AANLkTimu6VWUz=-8y-Gyccpw-rW+0aLpW5yu6A2G-AZ2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/12/12 Florian Pflug <fgp(at)phlo(dot)org>:
> On Dec12, 2010, at 00:19 , Pavel Stehule wrote:
>> I prefer a table based
>> solution, because I don't need a one "unnest", but other preferences
>> are valid too.
> That's fine with me.
>
>> I dissatisfied with your design of explicit target type
>> via unused value. I think, so we are not a infrastructure for it now
>> - from my view is better to use a common type, that is text now. It's
>> nothing new - plpgsql use it too.
> Sorry, I can't follow you here. Where does plpgsql use text as "common" type?
>
>> I see one well design of explicit target type based on polymorphic
>> types that respect a PostgreSQL fmgr practice:
>>
>> We have to allow a polymorphic functions without polymorphic
>> parameters. These functions shoud be designed to return value in
>> "unknown" type format when this function has not outer information.
> I don't think "unknown" is the right type for that. As far as I known, "unknown" is still a textual type, used to have some type to assign to string literals during parsing when no better type can be inferred.
>
>> This information can be passed in function context. When function
>> context isn't null, then function has to read target type and should
>> to return value in target type. Who can fill a function context? It is
>> task for executor. And when CAST contains just function call, then we
>> can recheck, if function is polymorphic, and if it is, then we can set
>> function context to target type, and then we don't need to call a
>> conversion function, because polymorphic function must returns data in
>> correct format.
> The main difficulty is that currently types are assigned in a bottom-up fashion as far as I know. To make functions with a polymorphic return value, but without polymorphic arguments work, you need to assign the return type in a top-down fashion (It depends on where to value *goes*, not where it *comes from*). That seems like a rather huge change and has the potential to complicate quite a few other parts, most notably function lookup/resolution.
>
> Plus, the general case where type information must bubble up more than one level seems pretty much intractable, as it'd require a full-blown type inference algorithm like ML or Haskell. Not a place where we want to go, I believe.
>
> The restricted case, on the other hand, brings very little benefit compared to the dummy-parameter approach. Yeah, "<polymorphic function>()::type" may look a bit cleaner than "<polymorphic function>(NULL::type)", but thats about is. It's only assignments in pl/pgsql which really benefit, since you'd be able to leave out the type completely, writing simply "v_value := <polymorphic_function>()". Does that really warrant the effort that'd be involved?
There is a second possibility - and hardly simpler. We can use a
specialised statement with own parser/executor node. Then
implementation should be really simply
syntax:
EXTRACT_VALUE(expr1 FROM expr2 AS typename) ... RETURNS typename
expr1 ... result must be converted to text .. fieldname
expr2 ... result must be composite type
disadvantage - EXTRACT_VALUE must be a keyword
advantage - simple implementation, available for all environments, readable
var := EXTRACT_VALUE('f1' FROM myrec AS int);
note: name for this statement isn't important now, can be EXTRACT_FIELD, ...
comments, ideas?
Regards
Pavel Stehule
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-12-13 07:28:17 | Re: pg_archivecleanup should remove WAL files also in pg_xlog? |
Previous Message | Fujii Masao | 2010-12-13 07:06:26 | Re: pg_archivecleanup should remove WAL files also in pg_xlog? |