Re: proof concept - access to session variables on client side

2012/6/26 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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 runtime,
> which is going to be disastrous for performance.  Quite aside from the
> network round trip involved, the fetch function would have to be marked
> volatile (since it has client-visible side-effects, not to mention that
> we don't know when the client might change the variable value); which
> would really hurt any query involving it, and probably lead to yet more
> round trips.

I didn't implement any optimization, because it is just concept, but
server side caching is possible. Then only "first read" and any
"write" can do some network communication.

>
> Pushing over the known values once at session start (and individual
> values after updates) is likely to be vastly better-performant than
> this.  Matters could be improved further by requiring variables to be
> sent to the server to be explicitly marked, which seems like a good
> idea anyway in case anybody has security concerns that they're not
> going to let you airily dismiss.
>

this is decision between push and pull model. Both variants has own
issues and benefits. Probably pull model has more complex changes in
protocol implementation. Push model needs more code on client side.
Propagation psql variables should be enabled some command line option
and can be disabled by default.

> Another thing I don't care for is the unannounced protocol extension.
> This feature is just not interesting enough to justify breaking
> client compatibility, but that's what it would do as proposed.
> Clients that haven't heard of this 'v' message would probably
> think they'd lost sync and drop the connection.
>

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.

> (BTW, the patch doesn't seem to include the added backend source file?)

The goal of this patch is showing requested functionality and checking
how hard is implementation

Regards

Pavel

>
>                        regards, tom lane