Re: Eurodates by default - Mailing list pgsql-patches
From | Yury Bokhoncovich |
---|---|
Subject | Re: Eurodates by default |
Date | |
Msg-id | Pine.LNX.4.33.0203200851510.12114-100000@panda.center-f1.ru Whole thread Raw |
In response to | Re: Eurodates by default (Peter Eisentraut <peter_e@gmx.net>) |
Responses |
Re: Eurodates by default
Re: Eurodates by default |
List | pgsql-patches |
Hello! On Tue, 19 Mar 2002, Peter Eisentraut wrote: > Yury Bokhoncovich writes: > > > They may silently ignore this option. Nothing has changed comparing > > with original behaviour if the option is not explicitly enabled. > > In fact it is alike --with-recode/locale configure options or target one and > > to make ease a sysadmin life and to save a few tciks of CPU: if I ALWAYS > > set Eurodates by default thru -o'e' option, why not do it at compile time > > rather than run time? > > The rules of the game are as follows: > > 1) If an option possibly can be a run-time option then it should be one > rather than a compile-time option. This allows users of binary packages > to have the same flexibility as users of the source code distribution. > (The --enable-locale option is actually slated for that kind of move > soon.) Having the option in both places is confusing. > > 2) No compile-time option may replace one behavior by another. This > allows binary packagers to make unbiased decisions about which options to > activate. (Note that --enable-locale does not replace behavior, it simply > adds more.) I'm not a binary packager. I configure and compile Pg by myself, thanks OpenSource. So I not care which bias that packager should select. Rather I care to avoid unnecessary (for me and kins) steps in the program. Anyway this closely resembles what with-maxbackends does: 1) if you have not specify with-maxbackends number, Pg will have some reasonable defaults (compile time, yes?) 2) you can change this value at run time (-N option or var in conf file) Are you planning to delete that option too?;) Folks, I do not see any serious reason to avoid compile-time option for people whom know what they are doing. The rest can sleep with peace w/o it. Contrary, the benefit for me is certain: skipping unneccesary checks. If somebody does not know about, this means that man can live without it. There is many option in various software which i do not know what is it for. Nevertheless this prevents neither me nor packagers to compile with necessary options only. "IF" will cost something, why did it need if I ALWAYS set the same condition? This will be just an optional feature. > > What we want to do is integrate the SET DateStyle variable into GUC > somehow, but I'm not entirely happy with the current behavior and have > been unable to agree with Thomas Lockhart on how to do it. But it will > get done eventually. In case of DateStyle I need a values which will set Postgres,Euro per one hop. And there should be "-e" option in postmaster. Suggestions? I agree that variable in conf file looks better. BTW, why parse_datestyle_internal always returns TRUE? -- WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group. Phone: +7 (3832) 106228, ext.140, E-mail: byg@center-f1.ru. Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
pgsql-patches by date: