pá 26. 12. 2025 v 10:42 odesílatel zengman <[email protected]> napsal:
> Hi,
>
> If you are in a hurry, you can try modifying the code of 'orafce' in this
> way.
> ```
> postgres@zxm-VMware-Virtual-Platform:~/code/18/contrib/orafce$ git diff
> diff --git a/Makefile b/Makefile
> index ac72aa5..5772627 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -95,7 +95,7 @@ REGRESS = orafce\
>
> #REGRESS_OPTS = --load-language=plpgsql --schedule=parallel_schedule
> --encoding=utf8
> REGRESS_OPTS = --schedule=parallel_schedule --encoding=utf8
> -
> +override CFLAGS += -D'static_assert=_Static_assert'
> # override CFLAGS += -Wextra -Wimplicit-fallthrough=0
>
it can be temporal fix - what is interesting, I have no problem with build
of plpgql_check
>
> ifdef NO_PGXS
> diff --git a/datefce.c b/datefce.c
> index 3cc42cd..fc1e5d6 100644
> --- a/datefce.c
> +++ b/datefce.c
> @@ -1281,7 +1281,11 @@ orafce_sys_extract_utc_oracle_date(PG_FUNCTION_ARGS)
> {
> TimestampTz loc_ts;
>
> -#if PG_VERSION_NUM >= 130000
> +#if PG_VERSION_NUM >= 180000
> +
> + loc_ts = timestamp2timestamptz_safe(PG_GETARG_TIMESTAMP(0), NULL);
> +
> +#elif PG_VERSION_NUM >= 130000
>
> loc_ts =
> timestamp2timestamptz_opt_overflow(PG_GETARG_TIMESTAMP(0), NULL);
> ```
>
this is already fixed
>
> --
> Regards,
> Man Zeng
> www.openhalo.org
