Re: Polymorphic function calls

From: knizhnik <knizhnik(at)garret(dot)ru>
To: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Polymorphic function calls
Date: 2013-12-30 10:03:56
Message-ID: 52C1450C.1020506@garret.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/30/2013 01:22 AM, Sergey Konoplev wrote:
> On Sun, Dec 29, 2013 at 8:44 AM, knizhnik <knizhnik(at)garret(dot)ru> wrote:
>> create function volume(r base_table) returns integer as $$ begin return
>> r.x*r.y; end; $$ language plpgsql strict stable;
>> create function volume(r derived_table) returns integer as $$ begin return
>> r.x*r.y*r.z; end; $$ language plpgsql strict stable;
> [...]
>
>> Execution plans of first and second queries are very similar.
>> The difference is that type of r_1 in first query is "base_table".
>> It is obvious that query should return fixed set of columns, so
>>
>> select * from base_table;
>>
>> can not return "z" column.
>> But passing direved_table type instead of base_table type to volume()
>> function for record belonging to derived_table seems to be possible and not
>> contradicting something, isn't it?
> Correct.
>
> Postgres chooses a function based on the passed signature. When you
> specify base_table it will choose volume(base_table) and for
> base_table it will be volume(derived_table) as well.
I think you mean "and for derived_table it will be base_table as well".
Certainly I understand the reasons of such behavior and that it will be
difficult to introduce some other non-contradictory model...

But polymorphism is one of the basic features of OO approach. Definitely
PostgreSQL is not OODBMS. But it supports inheritance.
And I wonder if it is possible/desirable to make an exception for
function invocation rules for derived tables?

Actually a query on table with inherited tables is implemented as join
of several independent table traversals.
But for all derived tables we restrict context to the scope of base
table. If it is possible to leave real record type when it is passed to
some function, we can support polymorphic calls...

Will it violate some principles/rules? I am not sure...

>
> FYI, there is a common practice to follow the DRY principle with
> inheritance and polymorphic functions in Postgres. On your example it
> might be shown like this:
>
> create function volume(r base_table) returns integer as $$ begin
> return r.x*r.y;
> end; $$ language plpgsql strict stable;
>
> create function volume(r derived_table) returns integer as $$ begin
> return volume(r::base_table) *r.z;
> end; $$ language plpgsql strict stable;
>

I do not completely understand you here.
Function of derived class can refere to the overridden function when
it's result depends on result of the overridden function.
But it is not always true, for example you can derived class Circle from
Ellipse, but formula for circle volume do not need to use implementation
of volume for ellipse.

In any case, my question was not how to implement polymorphic volume
function.
I asked whether it is possible to change PostgreSQL function lookup
rules to support something like virtual calls.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-12-30 12:46:38 Re: [COMMITTERS] pgsql: Upgrade to Autoconf 2.69
Previous Message Marko Kreen 2013-12-30 10:02:54 Re: pgcrypto missing header file inclusions