Skip site navigation (1) Skip section navigation (2)

Re: Eurodates by default

From: Yury Bokhoncovich <byg(at)center-f1(dot)ru>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Eurodates by default
Date: 2002-03-20 08:49:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches

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(at)center-f1(dot)ru(dot)
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.

In response to


pgsql-patches by date

Next:From: Yury BokhoncovichDate: 2002-03-20 09:02:55
Subject: Re: Eurodates by default
Previous:From: Bruce MomjianDate: 2002-03-20 05:40:30
Subject: Re: Eurodates by default

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group