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 | Resend email |
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
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 |