Roland Bouman wrote: > Hi All, Monty, > >> If we move parsing out to the client, then we could implement pluggable >> types as a client-side addition, leaving the database server lean and >> mean, but still giving compile-time errors and data validation hooks. > > Ouch....so that means essentially you cannot index columns using user > defined types (at least not in a way that the index reflects > type-specific semantics. > > I can see how parsing could be moved to the client side. But surely, > query execution still lives at the server side, correct? I mean, > something like evaluating a WHERE clause to compare whether a > particular column is equal to some constant is done on the server no? > Isn't this impossible of the logic to perform the comparison is not > par of the server?
I don't think it has to be necessary for the index to _understand_ the type, as long as the type has a sensible byte encoding. Take the new decimal type, for instance. One of the nice things about it was that it was a compact binary representation that was still sortable without needing to be expanded. Same thing with IP addresses, right? If you throw binary version of one into a column, it'll sort fine and respond to equality fine. Yet you don't want to have to wrap all of your calls with inet_aton() or something. The server can then do things like find ranges or equalities of values, and the UDTs can take care of encoding or decoding those things into a form that makes sense for the user. No? but yes... query execution certainly has to happen on the server... else I'm not entirely sure what the server does. :) Monty _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
