Re: Review: B-Tree emulation for GIN

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: B-Tree emulation for GIN
Date: 2009-02-06 22:08:39
Message-ID: 1233958119.14070.60.camel@dell.linuxdev.us.dell.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2009-01-19 at 21:41 +0300, Teodor Sigaev wrote:
> > gin_numeric_cmp() can be called from regular SQL. I missed this before,
> > but that function will segfault if you call gin_numeric_cmp(NULL, 1) (in
> > v0.7 at least).
>
> Fixed, gin_numeric_cmp is marked as strict.
>
> > And how does GIN handle SQL NULL values in the column? Does it index
> > them at all, or just ignore them?
> SQL NULL: GIN doesn't support it (amindexnulls/amsearchnulls == false)
> C NULL: NULL-numeric could be returned only by gin_extract_query_numeric which
> cannot be called by user directly because of internal type of argument.
> GIN doesn't do anything with values returned by gin_extract_query_numeric except
> providing they as an argument for comparing functions.

Looking through the code again, gin_compare_prefix_##type looks a little
confusing.

Is there a reason for using:
(data->strategy == BTLessStrategyNumber ||
data->strategy == BTLessEqualStrategyNumber ) ?
PointerGetDatum(data->datum) : a
rather than just using:
PointerGetDatum(data->datum)

Also, it might be a little less confusing if you used two separate
variables rather than using "res" for two purposes.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira de Oliveira 2009-02-06 22:45:22 Re: autovacuum and reloptions
Previous Message Tom Lane 2009-02-06 21:40:00 Re: KOI8-U support (was Re: [BUGS] create database warning)