Thread: Eurodates by default
Hello! The patch adds a configure option which enables using eurodates in PgSQL by default (i.e. as if -e option of backend was given). The patch allows to get rid unconvenient -o'e' option for postmaster. IMHO this is pretty convenient for people like me whom likes POSTGRES-like date output (DD-MM-YYYY) but cannot afford American MM-DD-YY format. The patch touches 3 files; configure.in - to add the option globals.c - to change default definition of the appropriate variable (if necessary) pg_config.h.in - to define the respective compile-time constant if there is an interest, I could try to add similar global variable to guc.c (for use in postgresql.conf). -- 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.
Attachment
Yury Bokhoncovich <byg@center-f1.ru> writes:
> The patch adds a configure option which enables using eurodates in PgSQL
> by default (i.e. as if -e option of backend was given).
> The patch allows to get rid unconvenient -o'e' option for postmaster.
This strikes me as *entirely* the wrong approach. A configure option
is very unwieldy (what of people who want to use RPM packages?).
Instead of wiring in the behavior at configure time, why not set up
a GUC variable?
regards, tom lane
Hello! On Tue, 19 Mar 2002, Tom Lane wrote: > Yury Bokhoncovich <byg@center-f1.ru> writes: > > The patch adds a configure option which enables using eurodates in PgSQL > > by default (i.e. as if -e option of backend was given). > > The patch allows to get rid unconvenient -o'e' option for postmaster. > > This strikes me as *entirely* the wrong approach. A configure option > is very unwieldy (what of people who want to use RPM packages?). 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? > > Instead of wiring in the behavior at configure time, why not set up > a GUC variable? There is no such variable. Yes, I could try to fix it but I'm not sure I can. Initially, I wanted to add -e option directly to postmaster but after some speculation I discard this idea for reason similar to your "wrong approach". -- 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.
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.) 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. -- Peter Eisentraut peter_e@gmx.net
> 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. Can I have a TODO line for this? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
(redirected to -hackers)
...
> 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.
Hmm. I've sensed a general unhappiness with most of the world's time
zones recently ;)
But I'm afraid I'm not recalling the specific issues associated with GUC
vs no-GUC. What in the current behavior of date and time needs to
change? Is it locale issues (which for non-ISO date input and output is
a can of worms by itself) or something else?
- Thomas
Thomas Lockhart writes: > But I'm afraid I'm not recalling the specific issues associated with GUC > vs no-GUC. What in the current behavior of date and time needs to > change? Is it locale issues (which for non-ISO date input and output is > a can of worms by itself) or something else? One issues was that the semantics of DateStyle don't fit well into GUC. DateStyle takes one or two strings and sets one or two integer variables. GUC basically only supports once argument setting one variable of equal type. It can probably still be made to work with all the hooks that are in place, but it doesn't look pretty. I had once suggested splitting up DateStyle into two variables, one for the "style" and for the day/month order. I think this is ultimately clearer to the user, too. Others have suggested generalizing the "style" aspect to take a to_char format. This comes with its own set of problems. -- Peter Eisentraut peter_e@gmx.net
> I had once suggested splitting up DateStyle into two variables, one for > the "style" and for the day/month order. I think this is ultimately > clearer to the user, too. I have found the two-value nature of Datestyle quite confusing myself. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
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.
Hello! On Tue, 19 Mar 2002, Peter Eisentraut wrote: > One issues was that the semantics of DateStyle don't fit well into GUC. > DateStyle takes one or two strings and sets one or two integer variables. > GUC basically only supports once argument setting one variable of equal > type. It can probably still be made to work with all the hooks that are > in place, but it doesn't look pretty. > > I had once suggested splitting up DateStyle into two variables, one for > the "style" and for the day/month order. I think this is ultimately > clearer to the user, too. I think it's better to split "datestyle" (representation, separator, etc., there is many ways) and "eurodates" (order, de-facto european vs american - I don't know about any other). The former fits well to string type, the latter fits to boolean one. > > Others have suggested generalizing the "style" aspect to take a to_char > format. This comes with its own set of problems. I don't like this: unclear and not easy. Though there is a reason to do that 'cos it will be more similar to Oracle (forget exact name of the env. variable fully controlling date format). -- 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.
Yury Bokhoncovich <byg@center-f1.ru> writes:
> 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?;)
A poor choice of example, because in fact I am planning to delete it ;-).
There's no need for it anymore, because there's no longer any compile-
time limit on MaxBackends. In general we'd like to move away from
compile-time feature settings, except for cases like SSL or Kerberos
support where the feature depends on software you may not have.
I don't really see why you think it's preferable to use an extra
configure switch than to set a variable in postgresql.conf.
regards, tom lane
Yury Bokhoncovich wrote:
> [...]
>
> 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?
As suggested before, do it with GUC variables. This means you
can have compile time defaults that can be overridden in the
config file or with startup options.
GUC variables are the preferred mechanism for that sort of
thing nowadays in the PostgreSQL project. It might look easy
to you to code it as "-e" now, but add the amount of effort
you'd need to get that into the CVS (could be infinite) and
you'll realize that it's finally not the easy way.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com