Re: Client/Server compression?

Some questions for you at the end of this Tom...which I'd been thinking
about...and you touched on...hey, you did tell me to ask! :)

On Sat, 2002-03-16 at 14:38, Tom Lane wrote:
> Greg Copeland <greg(at)CopelandConsulting(dot)Net> writes:
> > I'm talking about something that would be optional. So, what's the cost
> > of having a little extra optional code in place?
>
> It costs just as much in maintenance effort even if hardly anyone uses
> it. Actually, probably it costs *more*, since seldom-used features
> tend to break without being noticed until late beta or post-release,
> when it's a lot more painful to fix 'em.

That wasn't really what I was asking...

>
> FWIW, I was not in favor of the SSL addition either, since (just as you
> say) it does nothing that couldn't be done with an SSH tunnel. If I had
> sole control of this project I would rip out the SSL code, in preference

Except we seemingly don't see eye to eye on it. SSH just is not very
useful in many situations simply because it may not always be
available. Now, bring Win32 platforms into the mix and SSH really isn't
an option at all...not without bringing extra boxes to the mix. Ack!

I guess I don't really understand why you seem to feel that items such
as compression and encryption don't belong...compression I can sorta
see, however, without supporting evidence one way or another, I guess I
don't understand resistance without knowing the whole picture. I would
certainly hope the jury would be out on this until some facts to paint a
picture are at least available. Encryption, on the other hard, clearly
DOES belong in the database (and not just I think so) and should not be
thrust onto other applications, such as SSH, when it may not be
available or politically risky to use. That of course, doesn't even
address the issues of where it may be unpractical for some users, types
of applications or platforms. SSH is a fine application which addresses
many issues, however, it certainly is not an end-all do all
encryption/compression solution. Does that mean SSL should be the
native encryption solution? I'm not sure I have an answer to that,
however, encryption should be natively available IMOHO.

As for the laundry list of items...those are simply issues that should
of been worked out prior to it being merged into the code..it migrated
to being a maintenance issue. That's not really applicable to most
situations if an implementation is well coded and complete prior to it
being merged into the code base. Lastly, stating that a maintenance
cost of one implementation is a shared cost for all unrelated sections
of code is naive at best. Generally speaking, the level of maintenance
is inversely proportional to the quality of a specific design and
implementation.

At this point in time, I'm fairly sure I'm going to code up a
compression layer to play with. If it never gets accepted, I'm pretty
sure I'm okay with that. I guess if it's truly worthy, it can always
reside in the contributed section. On the other hand, if value can be
found in such an implementation and all things being equal, I guess I
wouldn't understand why it wouldn't be accepted.

================================
questions
================================

If I implement compression between the BE and the FE libpq, does that
mean that it needs to be added to the other interfaces as well? Do all
interfaces (JDBC, ODBC, etc) receive the same BE messages?

Is there any documentation which covers the current protocol
implementation? Specifically, I'm interested in the negotiation
section...I have been read code already.

Have you never had to support a database via modem? I have and I can
tell you, compression was God-sent. You do realize that this situation
if more common that you seem to think it is? Maybe not for Postgres
databases now...but for databases in general.

Greg