[dev] MSSQL portability options

[Eric Jon Rostetter]

Quoting Ben Chavet <ben at horde.org>:

> Ok, I think I've got the root of the mssql issues figured out.  It
> seems that when mssql returns an "empty" string, it could really be an
> empty string, or it could be a string of one or more spaces, making
> empty-string comparisons fail.  Yeah, it's dumb, I know.  BUT, the
> pear DB package has a portability option to take care of that,
> DB_PORTABILITY_RTRIM, which just does an rtrim on all of the values
> returned.
>
> So, how much of a performance hit would it be to turn on that flag for
> other databases?

I would think it would be at least some performance hit, but I don't know
how much.

I will say there is one potential case where it _might_ be useful for
postgresql...   Sometimes, if you do a pg_dumpall followed by a restore
(moving to a new machine, upgrading software, etc) it appends space characters
at the end of fields.  Doing the RTRIM would help in this case...

I'm not sure if that is worth making it a standard part of the pgsql
code or not though.  It is a rather fringe case...

> It needs to be turned on for mssql, so do we turn it
> on by default with the other portability flags we use, or do we make
> mssql a special case, and make the code a bit uglier?
>
> Thoughts?

I have no real idea, but I would lean towards making it an option for
mssql only personally.  I wouldn't object to it being on for all though,
unless it is or proves to be a noticable performance hit...

> --Ben


-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Go Longhorns!