Could postgres be much cleaner if a future release skipped backward compatibility? - Mailing list pgsql-hackers

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 fartoo late to change it), subscripting of fixed-length
arraytypesstarts from zero, rather than from one as for variable-length arrays. "
 

"Most of the alternative names listed in the "Aliases" column arethe names used internally by PostgreSQL for historical
reasons.Inaddition, some internally used or deprecated types are available,but are not listed here. "
 

"Note:  The name "oid2name" is historical, and is actuallyrather misleading"

"Note:  Native Kerberos authentication has been deprecatedand should be used only for backward compatibility."

"Old-style functions are now deprecated because of portabilityproblems and lack of functionality, but they are
stillsupportedfor compatibility reasons. "
 

"Although they still work, they are deprecated due to poorerror handling, inconvenient methods of detecting
end-of-data,andlack of support for binary or nonblocking transfers."
 

"The PostgreSQL usage of SELECT INTO to represent tablecreation is historical. It is best to use CREATE TABLE ASfor
thispurpose 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
syntaxinstead."
 

"The CAST syntax conforms to SQL; the syntax with :: is historicalPostgreSQL  usage."

"timeofday() is a historical PostgreSQL function."

"(This does not match non-slice behavior and is done forhistorical reasons.)"

"The SQL standard requires the use of the ISO 8601 format. The name ofthe "SQL" output format is a historical
accident."

"attribute ... The historical way to specify optional pieces ofinformation about the function. "
Caution

"Caution: If the configuration parameter standard_conforming_stringsis off, then PostgreSQL recognizes backslash
escapesin both regularand escape string constants. This is for backward compatibilitywith 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 aboolean result; instead it has to store the flag at the
locationindicatedby the third argument. "
 

"For historical reasons, there are two levels of notice handling,"

"Note that subscripting is 1-based, whereas for historicalreasons proargtypes is subscripted from 0 "

"The term attribute is equivalent to column and is usedfor historical reasons. "

"For historical reasons, ALTER TABLE can be used withsequences too; but the only variants of ALTER TABLEthat are
allowedwith 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;"