2014-09-18 13:59 GMT+02:00 Pavel Stehule <pavel.steh...@gmail.com>:
>
>
> 2014-09-18 13:53 GMT+02:00 Andres Freund <and...@2ndquadrant.com>:
>
>> On 2014-09-18 13:51:56 +0200, Pavel Stehule wrote:
>> > 2014-09-18 13:48 GMT+02:00 Andres Freund <and...@2ndquadrant.com>:
>> >
>> > > On 2014-09-18 13:44:47 +0200, Pavel Stehule wrote:
>> > > Isn't being able to do this on a standby a fundamental enough
>> advantage?
>> > > Being significantly cheaper? Needing fewer roundtrips?
>> > >
>> >
>> > no, I don't need more. My opinion is, so this proposal has no real
>> benefit,
>> > but will do implement redundant functionality.
>>
>> FFS: What's redundant about being able to do this on a standby?
>>
>
> Is it solution for standby? It is necessary? You can have a functions on
> master.
>
> Is not higher missfeature temporary tables on stanby?
>
> again: I am not against to DO paramaterization. I am against to implement
> DO with complexity like functions. If we have a problem with standby, then
> we have to fix it correctly. There is a issue with temp tables, temp
> sequences, temp functions.
>
if we would to need a "single use" function, then we should to implement
it, and we should not to rape some different objects. Some, what has behave
like function should be function.
After some thinking, probably CTE design can be only one frame, where we
can do it
WITH
FUNCTION f1(a int) RETURNS int AS $$ .. $$ LANGUAGE plpgsql,
FUNCTION f2(a int) RETURNS SETOF int AS $$ .. $$ LANGUAGE plpgsql,
SELECT f1(x) FROM f2(z) LATERAL ....
We can generalize WITH clause, so there SEQENCES, VIEWS, .. can be defined
for "single usage"
Regards
Pavel
>
> Pavel
>
>
>
>>
>> Greetings,
>>
>> Andres Freund
>>
>> --
>> Andres Freund http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Training & Services
>>
>
>
