Re: Polymorphic function calls

From: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>
To: knizhnik <knizhnik(at)garret(dot)ru>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Polymorphic function calls
Date: 2013-12-29 21:22:20
Message-ID: CAL_0b1ucG8epj_HQc3GgKeORU88Abraysq8nX=-Ke=mrMhcYZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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;

--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray(dot)ru(at)gmail(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-12-29 21:35:14 Re: [BUG FIX] Version number expressed in octal form by mistake
Previous Message Tom Lane 2013-12-29 18:05:29 Re: [COMMITTERS] pgsql: Upgrade to Autoconf 2.69