Thread: tsearch2() trigger and domain types...
Okay, so I have an interesting problem that I'm having a hard time figuring out. For standardization in my database I use a domain (login_t) for my login column in my profile table. I'm trying to use the tsearch2() trigger to index several columns, including the login column, into a column called "search_index." So I added the trigger as attached with the hope that it would do just that. Well, here's what I get upon every update and insert to the profile table: WARNING: TSearch: 'login' is not of character type I've tried casting and such, but nothing seems to work. Anybody got any ideas? Thanks in advance. -- ~ Michael D. Stemle, Jr. <>< (A)bort, (R)etry, (I)nfluence with large hammer 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
"Michael D. Stemle, Jr." <manchicken@notsosoft.net> writes:
> For standardization in my database I use a domain (login_t) for my login
> column in my profile table.
> Well, here's what I get upon every update and insert to the profile table:
> WARNING: TSearch: 'login' is not of character type
The tsearch trigger seems to insist that the column be text, varchar(n),
or char(n) ... no domains need apply :-(
I'm not real sure why it doesn't just invoke the column's output
function and be datatype-agnostic. Or at least do that when the
shortcut "I know what text looks like" path isn't applicable.
regards, tom lane
On Monday 18 June 2007 17:59:50 Tom Lane wrote: > "Michael D. Stemle, Jr." <manchicken@notsosoft.net> writes: > > For standardization in my database I use a domain (login_t) for my login > > column in my profile table. > > > > Well, here's what I get upon every update and insert to the profile > > table: WARNING: TSearch: 'login' is not of character type > > The tsearch trigger seems to insist that the column be text, varchar(n), > or char(n) ... no domains need apply :-( > > I'm not real sure why it doesn't just invoke the column's output > function and be datatype-agnostic. Or at least do that when the > shortcut "I know what text looks like" path isn't applicable. Is there any way to cast these column datatypes in the trigger to fool it, or is the only way to fix this to reconstruct the table without domains? I'd really prefer not to abandon domains if at all possible. -- ~ manchicken <>< (A)bort, (R)etry, (I)nfluence with large hammer. 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
manchicken <manchicken@notsosoft.net> writes:
> Is there any way to cast these column datatypes in the trigger to fool it,
No, you'd have to modify the trigger source code. It'd be a pretty
trivial change to allow domains over textual types:
continue; } oidtype = SPI_gettypeid(rel->rd_att, numattr);
+ oidtype = getBaseType(oidtype); /* We assume char() and varchar() are binary-equivalent to text */ if
(!(oidtype== TEXTOID || oidtype == VARCHAROID || oidtype == BPCHAROID)) { elog(WARNING,
"TSearch:'%s' is not of character type", trigger->tgargs[i]);
regards, tom lane
On Tuesday 19 June 2007 09:08:23 Tom Lane wrote: > oidtype = getBaseType(oidtype); I patched this in a FreeBSD 6.2 port. Attached is the patch. Thanks a lot for the help on this. It works like a charm. -- ~ manchicken <>< (A)bort, (R)etry, (I)nfluence with large hammer. 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html