Re: GiST on 64-bit box
От | Tom Lane |
---|---|
Тема | Re: GiST on 64-bit box |
Дата | |
Msg-id | 24524.1013190138@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: GiST on 64-bit box (Teodor Sigaev <teodor@stack.net>) |
Ответы |
Re: GiST on 64-bit box
|
Список | pgsql-hackers |
Teodor Sigaev <teodor@stack.net> writes: > My opinion is that second way is right (use GISTENTRY array). But this > channge requires changes in GiST API: picksplit and union functions > must retrieve one argument more. Is it possible to make for 7.2.1 or > such changes must be appyed in TODO for 7.3 ? Hmm. If we had any such functions installed in the standard system, then such a change would mean an initdb, which we couldn't do for 7.2.1. We could argue that forcing a change in a contrib module isn't an initdb, but the argument will seem very thin to anyone who has a running 7.2 database with GIST indexes and wants to update to 7.2.1. They will have to reinstall their GIST support modules and recreate their GIST indexes, AFAICS. On the other hand, changing the signature would be a good thing if the GIST code were tweaked to check that the referenced function had the right signature, because that way you could raise an error at runtime if someone tried to use a non-updated contrib module with an updated backend. Without some such check I foresee disasters in the field. So I think I vote for changing the signature and tweaking initGISTstate to verify that the number of parameters each function expects is right. But even with that, it might be argued that we should postpone the change till 7.3, and just say "sorry folks, GIST doesn't work on 64-bit machines for now". Is that worse than risking update problems for existing users of GIST indexes? Comments anyone? regards, tom lane
В списке pgsql-hackers по дате отправления: