"Darren King" <[EMAIL PROTECTED]> writes:
> How about creating an SQL statement that will make the change and
> putting a blurb about it it in the README, INSTALL and/or FAQ?
In theory we could do that, but I doubt it's worth the trouble.
Hash on macaddr has never worked (until my upcoming commit
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
hashable. Either change will not take effect without an initdb,
however, and I'm loath to force one now that we've started beta.
>>
>> If we're going to add CRC to log then we need
>> in beta anyway...
> Ops - we need in INITDB...
Not to m
> We could fix this either by adding a new hash function to support
> macaddr, or by removing the pg_amXXX entries that claim macaddr is
> hashable. Either change will not take effect without an initdb,
> however, and I'm loath to force one now that we've started beta.
How about creating an SQL
> > We could fix this either by adding a new hash function to support
> > macaddr, or by removing the pg_amXXX entries that claim macaddr is
> > hashable. Either change will not take effect without an initdb,
> > however, and I'm loath to force one now that we've started beta.
>
> If we're going
> We could fix this either by adding a new hash function to support
> macaddr, or by removing the pg_amXXX entries that claim macaddr is
> hashable. Either change will not take effect without an initdb,
> however, and I'm loath to force one now that we've started beta.
If we're going to add CRC
It was just pointed out on pggeneral that hash indexes on macaddr
columns don't work. Looking into it, I find that someone (me :-()
made a booboo: pg_amproc claims that hashvarlena is the appropriate
hash function for macaddr --- but macaddr isn't a varlena type,
it's a fixed-length pass-by-refer
