Re: [BUGS] BUG #9652: inet types don't support min/max

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [BUGS] BUG #9652: inet types don't support min/max
Дата
Msg-id 20140603095139.GK24145@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #9652: inet types don't support min/max  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: [BUGS] BUG #9652: inet types don't support min/max  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2014-06-03 12:43:28 +1000, Haribabu Kommi wrote:
> *** a/src/test/regress/expected/create_function_3.out
> --- b/src/test/regress/expected/create_function_3.out
> ***************
> *** 153,389 **** RESET SESSION AUTHORIZATION;
>   SELECT proname, prorettype::regtype, proargtypes::regtype[]
>          FROM pg_proc JOIN pg_namespace ON pronamespace = pg_namespace.oid
>          WHERE nspname = 'pg_catalog' AND proleakproof ORDER BY proname;
> !     proname     | prorettype |                             proargtypes                             
> ! ----------------+------------+---------------------------------------------------------------------
> !  abstimeeq      | boolean    | [0:1]={abstime,abstime}
...
> !  xideq          | boolean    | [0:1]={xid,xid}
> ! (228 rows)
>   
>   --
>   -- CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT
> --- 153,391 ----
>   SELECT proname, prorettype::regtype, proargtypes::regtype[]
>          FROM pg_proc JOIN pg_namespace ON pronamespace = pg_namespace.oid
>          WHERE nspname = 'pg_catalog' AND proleakproof ORDER BY proname;
> !      proname     | prorettype |                             proargtypes                             
> ! -----------------+------------+---------------------------------------------------------------------
> !  abstimeeq       | boolean    | [0:1]={abstime,abstime}
...
> !  xideq           | boolean    | [0:1]={xid,xid}
> ! (230 rows)

I didn't reall look at the patch, but it very much looks to me like that
query result could use the \a\t treatment that rules.sql and
sanity_check.sql got. It's hard to see the actual difference
before/after the patch.
I'll patch that now, to reduce the likelihood of changes there causing
conflicts for more people.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: pg_stat directory and pg_stat_statements
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Proposing pg_hibernate