| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: GIN versus zero-key queries |
| Date: | 2009-03-26 20:45:37 |
| Message-ID: | 1238100337.11547.79.camel@dell.linuxdev.us.dell.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2009-03-25 at 13:25 -0400, Tom Lane wrote:
> I am not sure whether the statement in 52.5 is still accurate, though.
> We have an API definition by which extractQuery can distinguish "all
> match" from "no match". If we just legislate that "some match" isn't
> a valid behavior for zero-key queries, then the code is correct and the
> documentation is wrong. However, if the above quote is correct, then
> I think newScanKey() is buggy.
Legislating that "some match" is invalid for zero-key queries seems
reasonable to me.
If the operator class author wants it to throw an error for zero keys
(as the documentation says should happen), they can do that easily
enough without being forced. However, if the opclass author finds "all
match" to be useful behavior (which seems reasonable), I don't see a
reason to stop them.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2009-03-26 21:23:48 | Re: maintenance_work_mem and autovacuum |
| Previous Message | Josh Berkus | 2009-03-26 20:43:45 | Re: maintenance_work_mem and autovacuum |