推 ronlee543:謝謝您的熱心，完全講出了我心中的話 02/20 10:04
這篇文章之後，我應該不會再針對 ansi_padding 這個系列再PO文。
因為，感覺上我講的已經開始重複鬼打牆了，再說也還是一樣的事。
當然啦! 還是歡迎大家指教，我會聽，但不會再寫。:)
事情的起因是ronlee543問到為什麼 ansi_padding 一定要是ON，這
樣不是會多一些不必要的空白嗎?
TeemingVoid: 預設為 ON 比較有彈性，要不要空白都順我們的意。
trueQoo: 這個選項是「向前相容」。
trueQoo: 讓 char 與 varchar 有別區別。
Adonisy: 所以 ansi_padding 之前是為了向前相容無誤, 但以後拿
掉也很正常,只是不用期待他何時拿掉
說實在的，我想給原PO一個拍拍，因為，我們說了半天，都沒有回答
他的問題: 究竟有什麼理由，ansi_padding 一定不可以是 OFF 呢?
我贊成 ansi_padding 設為 ON，所以說了一個使用上的理由，自我
說服：好吧！就聽微軟的，反正這樣比較好。
trueQoo說出 ansi_padding 出現的緣由。但我認為「前向相容」絕
對不是這個選項該退出江湖的原因，因為 ansi_padding 跟其他選項
不同，設為 OFF，建立的那個資料表就是會砍掉結尾空白，就算你設
回ON，那個表還是會砍掉結尾空白。偏偏這個選項又這麼多年了，所
以如果我們重視「前向相容」，反而應該留著這個選項。
Adonisy的回文內容，在我的理解，是說這個選項既然有生，自然有滅，
完成階段任務後，隨時可以除役。但是，我還是認為這個選項在完成
其階段任務的期間，恐怕也創造了一些「歷史共業」。
在我認為，上述事項都不足以是 ansi_* 非死不可的關鍵。我們三人，
沒有一人提出一個無可反駁的原因，說明為什麼 ansi_padding 一定只
能是 ON。
究竟有什麼重大的危害，所以 ansi_padding 一定要是 ON? 如果有，
不會過了十多年都沒事。如果沒有，為什麼沒事要改成只能 ON?
經過這幾天，我反而想問跟ronlee543一樣的問題，為什麼ansi_padding
非死不可? 想設成 OFF 的，就用 OFF，免去 ASP 年代老是 string too
long... truncated 的錯誤訊息。想設成 ON 的，就用 ON 啊! 各人造
業各人擔。
有什麼理由為什麼 ansi_padding 一定只能是 ON 呢?
我會聽，但不會再說了，謝謝大家喔! ^_^
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.41.100.79
※ 編輯: TeemingVoid 來自: 114.41.100.79 (02/18 20:18)