Re: [Bulk] Re: quoted identifier behaviour

Ted Byers wrote:
>
> ----- Original Message ----- From: "Randall Smith" <randall(at)tnr(dot)cc>
>>
>> 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