functional index arg matching patch

Started by Mark Hollomonover 25 years ago4 messageshackers
Jump to latest
#1Mark Hollomon
mhh@mindspring.com

Attached is a patch to allow
functinal indecies to use functions that
are for 'binary-compatible' types.

eg

create function foobar(text) returns text as ....

create table vc ( a varchar );

create index on vc ( foobar(a) );

should now work.

--
Mark Hollomon
mhh@mindspring.com

Attachments:

index.patchtext/plain; charset=us-asciiDownload+106-104
#2Mark Hollomon
mhh@nortelnetworks.com
In reply to: Mark Hollomon (#1)
Re: functional index arg matching patch

Tom Lane wrote:

Mark Hollomon <mhh@mindspring.com> writes:

Attached is a patch to allow
functinal indecies to use functions that
are for 'binary-compatible' types.

Um, thanks for working on this, but I already fixed that...

regards, tom lane

When? A message you sent on 8-11 indicated it wasn't.

And I didn't see any code in CVS as of ~ 8-17
when I started. But I may have missed it.

I'll be interested in seeing how you
did it.

--

Mark Hollomon
mhh@nortelnetworks.com

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mark Hollomon (#2)
Re: functional index arg matching patch

"Mark Hollomon" <mhh@nortelnetworks.com> writes:

Tom Lane wrote:

Um, thanks for working on this, but I already fixed that...

When? A message you sent on 8-11 indicated it wasn't.

(Checks CVS) ... yesterday, actually.

I'll be interested in seeing how you did it.

I just called the ambiguous-function-name-resolution code in
parse_func.c and then checked to make sure it hadn't selected
something the executor wasn't prepared to cope with --- ie,
functions requiring runtime conversions of input data types.

It looked like you had copied out a bunch of the parse_func.c code,
which is OK in the short run but the duplicated code might be
a headache to keep in sync later on.

regards, tom lane

#4Mark Hollomon
mhh@nortelnetworks.com
In reply to: Mark Hollomon (#1)
Re: functional index arg matching patch

Tom Lane wrote:

"Mark Hollomon" <mhh@nortelnetworks.com> writes:

Tom Lane wrote:

Um, thanks for working on this, but I already fixed that...

When? A message you sent on 8-11 indicated it wasn't.

(Checks CVS) ... yesterday, actually.

Yea, I saw it when a refreshed last night.

I'll be interested in seeing how you did it.

I just called the ambiguous-function-name-resolution code in
parse_func.c and then checked to make sure it hadn't selected
something the executor wasn't prepared to cope with --- ie,
functions requiring runtime conversions of input data types.

It looked like you had copied out a bunch of the parse_func.c code,
which is OK in the short run but the duplicated code might be
a headache to keep in sync later on.

I had thought about doing it the way you did, but didn't know the
consequences of some of the other coersions that parse_func.c
tried to do. My guess that it wasn't harmless was correct judging from
your code.

--

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008