Ted Byers wrote:
----- Original Message ----- From: "Randall Smith" <randall@xxxxxx>
I'll give the pghackers forum a visit and since I'm already on the
subject here, I'll make a direct comparison of the situation.
Microsoft's Internet Explorer web browser is known to have poor
support for the CSS standard, but refuses to fix it saying that it's
too difficult and would break existing websites. Many developers,
myself included, prefer to code to the standard and have the html/css
render correctly in all browsers. In the long run, it's better to do
it right even if that means breaking things today. If the standard is
good (there are poor standards), there's no reason to not use the
standard.
In principle, I don't disagree with you. However, I tend to be much
more pragmatic. Often we have little choice in the tools we use. I
have seen occasions where developers were constrained to use MS Visual
Studio. It is an outstanding product now (I have, and use the
professional edition of MS VS 2005). However, MS VS v6 was mediocre at
best. And a majority of WIN32 developers had to use it. It was
popular despite its problems. It had very poor compliance to the ANSI
C++ standards at the turn of the century, although that isn't too
surprising given its age. But many people thought they were writing
standards compliant code, and that code broke big time once they tried
to use it with later, better, compilers. That is just one example.
Yours is another, and there examples relating to FORTRAN (is there
anyone other than me old enough to remember that? - I recently
encountered IT professionals who didn't know what punch cards where or
how they were used). Yet much FORTRAN code that is four or five decades
old is still valuable a) because it was written to a standard and b)
there are tools to automate converting it into C, allowing it to be used
while an old C++ programmer like myself adapts it to take advantage of
key C++ programming idioms and language features (templates, template
metaprogramming). This is because in many cases the core algorithms
developed at the time have not been supplanted by better ones, and they
are still essential for intensive number crunching. I have seen
technologies and standards come and go (or better, be upgraded), and
while we ought to write our code to be as compliant as possible to the
relevant standards, if there is one (there isn't one, last I checked,
for VB, Java or Perl), in the end our tools are the final arbiters of
what is legal and what isn't. Therefore, when the investment in the code
in question is significant, and only then, the most viable approach to
trying to preserve the value of the code is to use the highest common
factor between the standard and what the tools say the standard is (it
isn't unusual for tool developers to disagree about what the standard
really means, especially when dealing with some of the harder issues,
and nothing is as simple as it appears at first glance).
It is important to remember that standards change. Just compare the
different versions of the ANSI standard for SQL that have existed over
the years. Or do the same for some of the other languages such as
FORTRAN, C and C++. Since it is certain that even the best standards
will change, and that some of those changes will break existing code, I
do not believe it is worth getting paranoid or worried or upset just
because one or another of our favourite tools lacks perfect compliance
with the standard. I do not define what is right by what a standard has
to say. Rather, I define it according to whether or not the correct
answers are obtained and whether or not the application does for the
user what the user needs it to do. In this view, then, there are
multiple right options, and this takes us back to our tools being the
final arbiter of whether or not our code is correct.
So, I say that good standards are valuable tools that can be used to
preserve the value of code that carries significant investment. At the
same time, they are only tools and the value they provide may well pale
relative to other considerations. I disagree with you when you say
there's no reason not to use the (good) standard. Often tool developers
put considerable effort into providing features in addition to what the
standard specifies, often without compromising compliance to the
standard since often details are specified to be implementation
dependant. Regardless of their motives for doing so, there are good,
economic and practical reasons to use such features. The trick, if one
must worry about using the code fifty years from now, is to ensure that
implementation specific code is well separated from standard compliant
code and that it is well documented. That way, when the technology
evolves in a way that will likely break your code (as the coming demise
of MFC will certainly do to countless WIN32 applications), it becomes
easier to replace what is broken and preserve what is not broken.
HTH
Ted
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Wow! You've certainly put some thought into this. Although you say you
disagree, I think we do agree. Saying a good standard should be followed
leaves room for additional functionality not specified in that standard.
I think the SQL drafters knew SQL would not cover all the functionality
of a good database system, but wanted to provide an abstraction for
features common to most database systems. As such most applications
using SQL would ideally be database agnostic. A specialized application
is more likely to require RDMS specific features not included in the SQL
standard. It's just sad that even selecting table names doesn't work
across databases. It's not just Postgresql. MySQL (last time I
checked) uses the filesystem name, which can be case sensitive or not
based on what OS is running.
Randall
