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: | Raw Message | Whole Thread | 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 |