Re: 17f446784d54da827f74c2acc0fa772a41b92354 breaks orafce build

pá 26. 12. 2025 v 10:42 odesílatel zengman <zengman(at)halodbtech(dot)com> napsal:

> Hi,
>
> If you are in a hurry, you can try modifying the code of 'orafce' in this
> way.
> ```
> postgres(at)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