| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
| Cc: | Larry Rosenman <ler(at)lerctr(dot)org>, pgsql-hackers(at)hub(dot)org |
| Subject: | Re: mac.c |
| Date: | 2000-08-07 15:57:30 |
| Message-ID: | 6320.965663850@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> Why not implement like() and notlike() for macaddr data types which (if
> both args are macaddr) will compare on manufacturer's fields alone? That
> would seem to get all the functionality you might want.
That seems like an entirely unjustified overloading of the "LIKE"
operator. I don't see any reason why someone would expect a string-
pattern-match operator to have the semantics of "compare the
manufacturer part only" when applied to macaddr.
> That would avoid ginning up something artificial like a macaddr with
> some fields zeroed out.
If you don't like that, provide a function that extracts the
manufacturer part as a text string (and I guess another to extract the
low-order bits as text). Then a lookup to get the manufacturer name can
be done as a text-field search. There is plenty of precedent in the
inet/cidr functions for extracting portions of a data value as text
strings.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-08-07 15:59:38 | Re: 'GROUP BY' / 'DISTINCT' interaction bug? |
| Previous Message | Philip Warner | 2000-08-07 15:57:18 | Re: [HACKERS] Re: Trouble with float4 after upgrading from 6.5.3 to 7.0.2 |