Could postgres be much cleaner if a future release skipped backward compatibility? - Mailing list pgsql-hackers
From | Ron Mayer |
---|---|
Subject | Could postgres be much cleaner if a future release skipped backward compatibility? |
Date | |
Msg-id | 4ADCD558.1020100@cheapcomplexdevices.com Whole thread Raw |
In response to | Re: Controlling changes in plpgsql variable resolution (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Re: Could postgres be much cleaner if a future release skipped backward compatibility? |
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;"
pgsql-hackers by date: