Le 3 juil. 2012 à 19:53, Peter Eisentraut a écrit :
> I think it would be better if DO could be extended into some kind of
> "lambda", taking parameters and returning a value. Then you can use
> existing infrastructure for passing values and saving the return. It
> would also extend better to ot
On tis, 2012-06-26 at 07:06 +0200, Pavel Stehule wrote:
> A motivation is integration of possibilities of psql console together
> with stronger language - plpgsql. Second target is enabling
> possibility to save a result of some server side process in psql. It
> improve vars feature in psql.
I thi
2012/7/3 Peter Eisentraut :
> On tis, 2012-06-26 at 07:06 +0200, Pavel Stehule wrote:
>> A motivation is integration of possibilities of psql console together
>> with stronger language - plpgsql. Second target is enabling
>> possibility to save a result of some server side process in psql. It
>> im
2012/6/27 Tom Lane :
> Pavel Stehule writes:
>>> Another thing I don't care for is the unannounced protocol extension.
>
>> yes, it needs protocol extension and increasing version too. But I
>> don't afraid about dissynchronisation - server doesn't send 'v'
>> message when client doesn't support i
Pavel Stehule writes:
>> Another thing I don't care for is the unannounced protocol extension.
> yes, it needs protocol extension and increasing version too. But I
> don't afraid about dissynchronisation - server doesn't send 'v'
> message when client doesn't support it.
And you would know that
2012/6/26 Tom Lane :
> Pavel Stehule writes:
>> it is not security issue - just I dislike sending complete stack, when
>> just only one variable should be used.
>
> That's a pretty darn weak argument. If I read the patch correctly, what
> you're proposing involves a dynamic fetch from the client
Merlin Moncure writes:
> On Tue, Jun 26, 2012 at 3:05 AM, Magnus Hagander wrote:
>> But with a small change to psql they could, without the need for a
>> whole new type of variable. For example, psql could set all those
>> variable as "psql.", which could then be accessed
>> from the DO PL code j
Pavel Stehule writes:
> it is not security issue - just I dislike sending complete stack, when
> just only one variable should be used.
That's a pretty darn weak argument. If I read the patch correctly, what
you're proposing involves a dynamic fetch from the client at runtime,
which is going to
2012/6/26 Merlin Moncure :
> On Tue, Jun 26, 2012 at 3:05 AM, Magnus Hagander wrote:
>> But with a small change to psql they could, without the need for a
>> whole new type of variable. For example, psql could set all those
>> variable as "psql.", which could then be accessed
>> from the DO PL cod
On Tue, Jun 26, 2012 at 3:05 AM, Magnus Hagander wrote:
> But with a small change to psql they could, without the need for a
> whole new type of variable. For example, psql could set all those
> variable as "psql.", which could then be accessed
> from the DO PL code just fine.
That's a really nea
2012/6/26 David Fetter :
> On Tue, Jun 26, 2012 at 10:12:52AM +0200, Pavel Stehule wrote:
>> 2012/6/26 Magnus Hagander :
>> > On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule
>> > wrote:
>> >> 2012/6/26 Magnus Hagander :
>> >>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
>> >>> wrote:
>>
On Tue, Jun 26, 2012 at 10:12:52AM +0200, Pavel Stehule wrote:
> 2012/6/26 Magnus Hagander :
> > On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule
> > wrote:
> >> 2012/6/26 Magnus Hagander :
> >>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
> >>> wrote:
> Hello
>
> I worked on si
2012/6/26 Magnus Hagander :
> On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule
> wrote:
>> 2012/6/26 Magnus Hagander :
>>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
>>> wrote:
Hello
I worked on simple patch, that enable access from server side to
client side data. It add
On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule wrote:
> 2012/6/26 Magnus Hagander :
>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> I worked on simple patch, that enable access from server side to
>>> client side data. It add two new hooks to libpq - one for returni
2012/6/26 Magnus Hagander :
> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> I worked on simple patch, that enable access from server side to
>> client side data. It add two new hooks to libpq - one for returning of
>> local context, second for setting of local context.
>>
On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule wrote:
> Hello
>
> I worked on simple patch, that enable access from server side to
> client side data. It add two new hooks to libpq - one for returning of
> local context, second for setting of local context.
>
> A motivation is integration of possi
Hello
I worked on simple patch, that enable access from server side to
client side data. It add two new hooks to libpq - one for returning of
local context, second for setting of local context.
A motivation is integration of possibilities of psql console together
with stronger language - plpgsql.
17 matches
Mail list logo
