Tom Lane wrote: > What are the probabilities that the OpenACSes of the world will just > set the value to "backward compatible" instead of touching their code?
Would postgres get considerably cleaner if a hypothetical 9.0 release skipped backward compatibility and removed anything that's only maintained for historical reasons? I notice the docs are filled with passages like the quotes below - which suggest that there's a fair amount of stuff that might be done differently if it weren't for backward compatibility. "For historical reasons (i.e., this is clearly wrong but it's far too late to change it), subscripting of fixed-length array types starts from zero, rather than from one as for variable-length arrays. " "Most of the alternative names listed in the "Aliases" column are the names used internally by PostgreSQL for historical reasons. In addition, some internally used or deprecated types are available, but are not listed here. " "Note: The name "oid2name" is historical, and is actually rather misleading" "Note: Native Kerberos authentication has been deprecated and should be used only for backward compatibility." "Old-style functions are now deprecated because of portability problems and lack of functionality, but they are still supported for compatibility reasons. " "Although they still work, they are deprecated due to poor error handling, inconvenient methods of detecting end-of-data, and lack of support for binary or nonblocking transfers." "The PostgreSQL usage of SELECT INTO to represent table creation is historical. It is best to use CREATE TABLE AS for this purpose in new code. " "regular expression metasyntax ... option...m: historical synonym for n" "Such comments are more a historical artifact than a useful facility, and their use is deprecated; use the expanded syntax instead." "The CAST syntax conforms to SQL; the syntax with :: is historical PostgreSQL usage." "timeofday() is a historical PostgreSQL function." "(This does not match non-slice behavior and is done for historical reasons.)" "The SQL standard requires the use of the ISO 8601 format. The name of the "SQL" output format is a historical accident." "attribute ... The historical way to specify optional pieces of information about the function. " Caution "Caution: If the configuration parameter standard_conforming_strings is off, then PostgreSQL recognizes backslash escapes in both regular and escape string constants. This is for backward compatibility with the historical" "historical alias for stddev_samp ... historical alias for var_samp" "For historical reasons, this variable contains two independent components" "For historical reasons, the same function doesn't just return a boolean result; instead it has to store the flag at the location indicated by the third argument. " "For historical reasons, there are two levels of notice handling," "Note that subscripting is 1-based, whereas for historical reasons proargtypes is subscripted from 0 " "The term attribute is equivalent to column and is used for historical reasons. " "For historical reasons, ALTER TABLE can be used with sequences too; but the only variants of ALTER TABLE that are allowed with sequences are...." "While this still works, it is deprecated and the special meaning of \. can be expected to be removed in a future release." "Use of this parameter is deprecated as of PostgreSQL 8.3;" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
