Re: Anonymous code block with parameters

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Kalyanov Dmitry <kalyanov(dot)dmitry(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Anonymous code block with parameters
Date: 2014-09-22 23:20:50
Message-ID: 5420AED2.9010503@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On 22/09/14 22:58, Merlin Moncure wrote:
>>
>> Meh. Those aren't comparable. TEMPORARY TABLES/INDEXES/... all live
>> beyond a single statement. What's being discussed here doesn't.
>
> Even if that wasn't true, 'DO' doesn't involve changes to system
> catalogs whereas temporary functions would. With a little imagination
> I could come up a with a scenario involving a script of a whole bunch
> of repeated trivial DO statements which would involve a lot less
> beating on the system catalogs.
>
> When the data-modifying-with feature was considered, an implementation
> that relied on temp tables was rejected at least in part because of
> system catalog thrash and poorer performance for very trivial queries.
>
> So, to me, DO vs CREATE FUNCTION has nothing to do with passing
> arguments and/or returning data. It has to do with lifespan; single
> call of the function body only, use DO, otherwise, create a function.
>

Actually same thing happened with the DO implementation itself -
creating anonymous/hidden temporary functions in the background was also
considered but was decided it's not acceptable (for similar reason temp
tables were rejected for WITH).

So we decided at least twice already that this kind of solution is bad,
I don't know of any change that would invalidate the reasons for
deciding that way so I don't see why they would suddenly become
acceptable...

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-09-22 23:22:08 Re: RLS feature has been committed
Previous Message Andres Freund 2014-09-22 23:02:55 RLS feature has been committed