Re: value too long error
От | Greg Stark |
---|---|
Тема | Re: value too long error |
Дата | |
Msg-id | 87ptbwcov4.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: value too long error (Bill Moran <wmoran@potentialtech.com>) |
Список | pgsql-general |
Bill Moran <wmoran@potentialtech.com> writes: > Greg Stark wrote: > > > > Note that this is largely a C++ rule. In C++ accessing class members is very > > different and much less flexible than using class methods. Other OO languages > > are not universally so hobbled. > > Really? I can only assume you're referring to languages such as perl that have > ties (or equivalent capability). In that case, you're still accessing the data > through a method, it's just a more abstract abstraction. Or are you referring > to something else? Well the original motivation is that in C++ member references are handled as C structure member references which hard code the offset in the structure into the code. This means nearly any change to your class such as changing member ordering, changing data types, or adding a member anywhere but at the end introduces ABI changes that no linker can detect. Method references on the other hand are resolved by name by the linker. The linker can resolve problems and you can provide legacy fall-back methods for old code. So in C++ maintaining a stable ABI is much easier using method calls than member references. Languages such as Perl, or Lisp, or most any other OO languages not trying to maintain C style efficiency resolve member references by name so you can add or change the "order" of your members without introducing "abi" incompatibility. > The last thing we'd want is someone getting the wrong answer to a financial > query because they don't understand the schema. A much more reliable way is > to have them > > SELECT * FROM get_monthy_payment(month, account); so we know they're getting > the correct answer. Of course that doesn't really change the need for the person writing the query to understand the schema, it just changes which tools that person's working with. Whoever wrote get_monthy_payment could just as easily get the query wrong, especially since they seem to be a poor typist :) You can do the same thing without depending on stored procedures by enforcing that only low level modules of your application under the control of the same schema-aware people get to write SQL queries. Upper level modules are only allowed to call $account->get_monthly_payment($month). This has the advantage that if get_monthly_payment involves doing several queries and incorporating out-of-database information it can do so without forcing people to use awkward database procedural languages or imposing awkard apis. -- greg
В списке pgsql-general по дате отправления: