Re: New pg_lsn type doesn't have hash/btree opclasses

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: New pg_lsn type doesn't have hash/btree opclasses
Дата
Msg-id 20140506232253.GB555@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: New pg_lsn type doesn't have hash/btree opclasses  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: New pg_lsn type doesn't have hash/btree opclasses
Список pgsql-hackers
On 2014-05-07 08:16:38 +0900, Michael Paquier wrote:
> On Wed, May 7, 2014 at 8:07 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-05-06 22:49:07 +0900, Michael Paquier wrote:
> > FWIW, the format you're using makes applying the patch including the
> > commit message relatively hard. Consider using git format-patch.

> Could you be clearer? By applying a filterdiff command or by using git
> diff? The latter has been used for this patch.

As I said, consider using git format-patch. Then the patch can be
applied using git am. Resulting in a local commit including your
commit message.

> >> +/* handler for btree index operator */
> >> +Datum
> >> +pg_lsn_cmp(PG_FUNCTION_ARGS)
> >> +{
> >> +     XLogRecPtr lsn1 = PG_GETARG_LSN(0);
> >> +     XLogRecPtr lsn2 = PG_GETARG_LSN(1);
> >> +
> >> +     PG_RETURN_INT32(lsn1 == lsn2);
> >> +}
> >
> > This doesn't look correct. A cmp routine needs to return -1, 0, 1 when a
> > < b, a = b, a > b respectively. You'll only return 0 and 1 here.
> Thanks, I recalled that this morning as well... And my 2nd patch uses
> this flow instead:
> +Datum
> +pg_lsn_cmp(PG_FUNCTION_ARGS)
> +{
> +       XLogRecPtr lsn1 = PG_GETARG_LSN(0);
> +       XLogRecPtr lsn2 = PG_GETARG_LSN(1);
> +
> +       if (lsn1 < lsn2)
> +               PG_RETURN_INT32(-1);
> +       if (lsn1 > lsn2)
> +               PG_RETURN_INT32(1);
> +       PG_RETURN_INT32(0);
> +}

That's nearly what's in the patch I attached.

> >> +/* hash index support */
> >> +Datum
> >> +pg_lsn_hash(PG_FUNCTION_ARGS)
> >> +{
> >> +     XLogRecPtr lsn = PG_GETARG_LSN(0);
> >> +
> >> +     return hashint8(lsn);
> >> +}
> >
> > That can't be right either. There's at least two things wrong here:
> > a) hashint8 takes PG_FUNCTION_ARGS, not a Datum

> In this case you may consider changing timestamp_hash@time.c and
> time_hash@date.c as well :)

Uh. They're different:

Datum
timestamp_hash(PG_FUNCTION_ARGS)
{/* We can use either hashint8 or hashfloat8 directly */
#ifdef HAVE_INT64_TIMESTAMPreturn hashint8(fcinfo);
#elsereturn hashfloat8(fcinfo);
#endif
}
note it's passing fcinfo, not the datum as you do. Same with
time_hash.. In fact your version crashes when used because it's
dereferencing a int8 as a pointer inside hashfloat8.

Greetings,

Andres Freund

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



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: New pg_lsn type doesn't have hash/btree opclasses
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: New pg_lsn type doesn't have hash/btree opclasses