pgsql: Move DTK_ISODOW DTK_DOW and DTK_DOY to be type UNITS rather than
Move DTK_ISODOW DTK_DOW and DTK_DOY to be type UNITS rather than
RESERV. RESERV is meant for tokens like "now" and having them in that
category throws errors like these when used as an input date:
stark=# SELECT 'doy'::timestamptz;
ERROR: unexpected dtype 33 while parsing timestamptz "doy"
LINE 1: SELECT 'doy'::timestamptz;
^
stark=# SELECT 'dow'::timestamptz;
ERROR: unexpected dtype 32 while parsing timestamptz "dow"
LINE 1: SELECT 'dow'::timestamptz;
^
Found by LLVM's Libfuzzer
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/258ee1b635e43a37e901fd5f62bdd5f1087d65a5
Modified Files
--------------
src/backend/utils/adt/datetime.c | 6 +--
src/backend/utils/adt/timestamp.c | 80 ++++++++++++++++++-------------------
2 files changed, 43 insertions(+), 43 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Greg Stark <stark@mit.edu> writes:
Move DTK_ISODOW DTK_DOW and DTK_DOY to be type UNITS rather than
RESERV.
Shouldn't that get back-patched? Also, what about ecpg's copy
of the code?
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Sun, Sep 6, 2015 at 4:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Shouldn't that get back-patched?
Indeed. I was trying to work out the git workflow and making a token
effort to test it. I think I've done it now.
Also, what about ecpg's copy of the code?
That I hadn't thought of. Will look at it but it's after 4am here now
so I'll get to it tomorrow.
--
greg
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Sun, Sep 6, 2015 at 4:14 AM, Greg Stark <stark@mit.edu> wrote:
Also, what about ecpg's copy of the code?
That I hadn't thought of. Will look at it but it's after 4am here now
so I'll get to it tomorrow.
So the only mention of these constants I can find in ECPG is the
structures in dt_common.c. I don't see a any code using it and I'm not
clear what the purpose of having this structure is or the significance
of changing it. Is this sufficient? Is it even necessary?
diff --git a/src/interfaces/ecpg/pgtypeslib/dt_common.c
b/src/interfaces/ecpg/pgtypeslib/dt_common.c
index 7fe2982..01cdfa9 100644
*** a/src/interfaces/ecpg/pgtypeslib/dt_common.c
--- b/src/interfaces/ecpg/pgtypeslib/dt_common.c
***************
*** 123,130 **** static datetkn datetktbl[] = {
{"dec", MONTH, 12},
{"december", MONTH, 12},
{"dnt", TZ, 3600}, /* Dansk Normal Tid */
! {"dow", RESERV, DTK_DOW}, /* day of week */
! {"doy", RESERV, DTK_DOY}, /* day of year */
{"dst", DTZMOD, SECS_PER_HOUR},
#if 0
{"dusst", DTZ, 21600}, /* Dushanbe Summer Time */
--- 123,130 ----
{"dec", MONTH, 12},
{"december", MONTH, 12},
{"dnt", TZ, 3600}, /* Dansk Normal Tid */
! {"dow", UNITS, DTK_DOW}, /* day of week */
! {"doy", UNITS, DTK_DOY}, /* day of year */
{"dst", DTZMOD, SECS_PER_HOUR},
#if 0
{"dusst", DTZ, 21600}, /* Dushanbe Summer Time */
***************
*** 206,212 **** static datetkn datetktbl[] = {
{"irkst", DTZ, 32400}, /* Irkutsk Summer Time */
{"irkt", TZ, 28800}, /* Irkutsk Time */
{"irt", TZ, 12600}, /* Iran Time */
! {"isodow", RESERV, DTK_ISODOW}, /* ISO day of week, Sunday == 7 */
#if 0
isst
#endif
--- 206,212 ----
{"irkst", DTZ, 32400}, /* Irkutsk Summer Time */
{"irkt", TZ, 28800}, /* Irkutsk Time */
{"irt", TZ, 12600}, /* Iran Time */
! {"isodow", UNITS, DTK_ISODOW}, /* ISO day of week, Sunday == 7 */
#if 0
isst
#endif--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Stark <stark@mit.edu> writes:
Also, what about ecpg's copy of the code?
So the only mention of these constants I can find in ECPG is the
structures in dt_common.c. I don't see a any code using it and I'm not
clear what the purpose of having this structure is or the significance
of changing it. Is this sufficient? Is it even necessary?
Hm. It does look like these entries might be dead code so far as ecpg
is concerned. I'd still make the changes you illustrate, just to avoid
having the ecpg code diverge further than necessary from the backend.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers