Re:

From: Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com>
To: "Wappler, Robert" <rwappler(at)ophardt(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re:
Date: 2009-12-21 17:51:07
Message-ID: 92869e660912210951i31713962ga2d6df2e66c0e08e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2009/12/21 Wappler, Robert <rwappler(at)ophardt(dot)com>

> Hello,
>
> when defining functions, why can’t they take table-valued arguments? I do
> not see the sense of this restriction. When a function takes a table as an
> argument, whole tables could be transformed in an obvious way. Currently
> functions must operate row-wise (at least I haven’t found another way). This
> also limits the capabilities of joining the row-arguments, obviously this
> must be done before passing the arguments to the functions, instead of
> having one or more table-arguments and simply doing the joins within the
> function. Further, table valued arguments could lower the developer’s work
> to prepare the arguments before the function call and enabling each
> functions to care for them itself by transforming them for the
> implementation instead of introducing several more or less anonymous record
> types just for passing values from one function to another which often also
> carry implementation specific constraints. The structure of the code as a
> set of functions would also greatly improve.
>
>
SQL itself is a language which operates on data sets. Interesting, why you
need a functional interface here?

Could you give some example - what you want to achieve, and what's the
missing element?
( please add some DDL and code if possible ).

As you know, every table in postgres has its rowtype definition.

CREATE TABLE aaa ( ... );
CREATE FUNCTION aaa_do (aaa) ...;
SELECT aaa_do(aaa.*) from aaa;

but that's the row-wise way.

You can also operate on tables via their *names*:
SELECT somefunc( 'aaa' ); /* some dynamic SQL inside */

You will find some examples in contrib/tablefunc

>
>
> What does the optimizer do with this per-row-semantic, even if it is
> invoked on each row? Does it transform the queries within the function to
> directly work on the table and realize possible advantages from indexes and
> other techniques?
>
Yes that's what it does, in general.
But, if processing is all "canned" inside user defined functions, the
optimizer can't do it's job.

some example from you would be handy here too.

regards,

--
Filip Rembiałkowski
JID,mailto:filip(dot)rembialkowski(at)gmail(dot)com
http://filip.rembialkowski.net/

In response to

  • at 2009-12-21 15:47:06 from Wappler, Robert

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Erik Jones 2009-12-21 17:55:59 Re: Justifying a PG over MySQL approach to a project
Previous Message Israel Brewster 2009-12-21 17:39:21 Re: defining yuor own commands in PG ?