Re: [HACKERS] [PATCH] inet << indexability (take 3)

[Tom Lane]

Alex Pilosov <[EMAIL PROTECTED]> writes:
> I think this addresses all Tom's concerns. Tom? :)

Checked and applied ...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] [PATCH] inet << indexability

[Tom Lane]

Alex Pilosov <[EMAIL PROTECTED]> writes:
> I didn't want to make them user-visible, however, the alternative, IMHO,
> is worse, since these functions rely on network_broadcast and
> network_network to do the work, calling sequence would be:
> a) indxpath casts Datum to inet, passes to network_scan*
> b) network_scan will create new Datum, pass it to network_broadcast
> c) network_scan will extract inet from Datum returned
> d) indxpath will then cast inet back to Datum :)
> Which, I think, is pretty messy :)

Sure, but you could make them look like

Datum network_scan_first(Datum networkaddress)

without incurring any of that overhead.  (Anyway, Datum <-> inet* is
only a cast.)

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] [PATCH] inet << indexability

[Tom Lane]

Alex Pilosov <[EMAIL PROTECTED]> writes:
> Also, I have a question: I put in a regression test to check that the type
> can be indexed, by doing 'explain select ...'. However, the expected
> result may vary when the optimizer is tweaked. 

Yes, I'd noted that already in looking at your prior version.  I think
it's best not to do an EXPLAIN in the regress test, because I don't want
to have to touch the tests every time the cost functions are tweaked.
However, we can certainly check to make sure that the results of an
indexscan are what we expect.  Is the table set up so that this is a
useful test case?  For example, it'd be nice to check boundary
conditions (eg, try both << and <<= on a case where they should give
different results).

Do you have any thought of making network_scan_first and
network_scan_last user-visible functions?  (Offhand I see no use for
them to a user, but maybe you do.)  If not, I'd suggest not using the
fmgr call protocol for them, but just making them pass and return inet*,
or possibly Datum.  No need for the extra notational cruft of
DirectFunctionCall.

Another minor stylistic gripe is that you should use bool/true/false
where appropriate, not int/1/0.  Otherwise it looks pretty good.

Oh, one more thing: those dynloader/openbsd.h and psql/tab-complete.c
changes don't belong in this patch...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly