Le 3 juil. 2012 à 19:53, Peter Eisentraut pete...@gmx.net 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
2012/7/3 Peter Eisentraut pete...@gmx.net:
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.
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 think
2012/6/27 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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'
On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule pavel.steh...@gmail.com 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
2012/6/26 Magnus Hagander mag...@hagander.net:
On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule pavel.steh...@gmail.com
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
On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2012/6/26 Magnus Hagander mag...@hagander.net:
On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I worked on simple patch, that enable access from server side to
client side
2012/6/26 Magnus Hagander mag...@hagander.net:
On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2012/6/26 Magnus Hagander mag...@hagander.net:
On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I worked on simple patch, that
On Tue, Jun 26, 2012 at 10:12:52AM +0200, Pavel Stehule wrote:
2012/6/26 Magnus Hagander mag...@hagander.net:
On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2012/6/26 Magnus Hagander mag...@hagander.net:
On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
2012/6/26 David Fetter da...@fetter.org:
On Tue, Jun 26, 2012 at 10:12:52AM +0200, Pavel Stehule wrote:
2012/6/26 Magnus Hagander mag...@hagander.net:
On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2012/6/26 Magnus Hagander mag...@hagander.net:
On Tue, Jun
On Tue, Jun 26, 2012 at 3:05 AM, Magnus Hagander mag...@hagander.net 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.commandlinevarname, which could then be accessed
from the DO PL code
2012/6/26 Merlin Moncure mmonc...@gmail.com:
On Tue, Jun 26, 2012 at 3:05 AM, Magnus Hagander mag...@hagander.net 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.commandlinevarname,
Pavel Stehule pavel.steh...@gmail.com 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
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Jun 26, 2012 at 3:05 AM, Magnus Hagander mag...@hagander.net 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.commandlinevarname, which
2012/6/26 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Pavel Stehule pavel.steh...@gmail.com 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
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 -
17 matches
Mail list logo
