Thread

Re: 17f446784d54da827f74c2acc0fa772a41b92354 breaks orafce build

Pavel Stehule <pavel.stehule@gmail.com> — 2025-12-26T10:19:06Z

pá 26. 12. 2025 v 10:42 odesílatel zengman <zengman@halodbtech.com> 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