| Lists: | pgsql-hackers |
|---|
| From: | Yury Bokhoncovich <byg(at)center-f1(dot)ru> |
|---|---|
| To: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Changing constant in src/include/miscadmin.h |
| Date: | 2002-03-20 13:17:40 |
| Message-ID: | Pine.LNX.4.33.0203201902450.12114-100000@panda.center-f1.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
Hello!
Is it valid to change a constant in src/include/miscadmin.h?
===========================
@@ -150,10 +150,10 @@
#define MAXTZLEN 10 /* max TZ name len, not counting tr. null */
-#define USE_POSTGRES_DATES 0
#define USE_ISO_DATES 1
#define USE_SQL_DATES 2
#define USE_GERMAN_DATES 3
+#define USE_POSTGRES_DATES 4
extern int DateStyle;
extern bool EuroDates;
===========================
This can make easy parsing of date style in parse_datestyle_internal
function (src/backend/commands/variable.c) in this way:
datestyle=0;
if () datestyle=USE_xxx
...
if (!datestyle) elog(ERROR
--
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.
| From: | Thomas Lockhart <thomas(at)fourpalms(dot)org> |
|---|---|
| To: | Yury Bokhoncovich <byg(at)center-f1(dot)ru> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Changing constant in src/include/miscadmin.h |
| Date: | 2002-03-20 15:10:32 |
| Message-ID: | 3C98A668.8D569A1B@fourpalms.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
> Is it valid to change a constant in src/include/miscadmin.h?
> -#define USE_POSTGRES_DATES 0
> +#define USE_POSTGRES_DATES 4
Yes, the code should still work and afaik these values are not embedded
anywhere other than in the compiled code so you will stay
self-consistant.
> This can make easy parsing of date style in parse_datestyle_internal
> function (src/backend/commands/variable.c) in this way:
> datestyle=0;
> if () datestyle=USE_xxx
> ...
> if (!datestyle) elog(ERROR
At the moment, one is allowed to call parse_datestyle_internal() only
setting the "european" vs "noneuropean" flag for month and day
interpretation. So the code should not have the check mentioned above.
Also, I would suggest using an explicit comparison rather than an
implicit comparison against zero. Something like
#define DATESTYLE_NOT_SPECIFIED 0
datestyle = DATESTYLE_NOT_SPECIFIED
...
if (datestyle == DATESTYLE_NOT_SPECIFIED) elog()...
where the #define is in the same place as the USE_xxx definitions. That
way you aren't relying on someone remembering that they *shouldn't* use
zero as one of the possible valid values. And that way the
DATESTYLE_NOT_SPECIFIED does not actually have to be zero.
- Thomas