Re: value too long error

From: Bill Moran <wmoran(at)potentialtech(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: value too long error
Date: 2004-03-01 18:09:35
Message-ID: 40437C5F.5070607@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Greg Stark wrote:
> Bill Moran <wmoran(at)potentialtech(dot)com> writes:
>
>>In OO programming, the generally accepted rule is that a program shouldn't
>>access class values directly, but the class should have methods to set
>>and retrieve the data. This allows internal representations to change
>>without affecting the public API of the class. It also allows data
>>validation to occur, if needed.
>
> 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?

>>I'm just wondering how far this rule of thumb could/should be extended to
>>databases? I mean, you could say: "Nobody does a direct INSERT, but always
>>calls a stored procedure that stores the result." I don't know how much
>>this might break the mindset of the client developer.
>
> This is a popular old-school database approach. Personally I find it
> incredibly annoying, but I can see its advantages as well. But to me stored
> procedures just don't seem like nearly a powerful enough abstraction tool to
> make them worth all the pain this approach entails.

I threw it out there for the sake of discussion. I can see advantages and
disadvantages. For example, I'm working on financial software, and
_everything_ is accessed through stored procedures. This is A Good Think
(in my opinion) because the software is designed to be easily integrated
with other systems. 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.

But I _can_ see the potential PITA this can cause. I guess it depends on
the circumstance.

--
Bill Moran
Potential Technologies
http://www.potentialtech.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruno Wolff III 2004-03-01 19:11:41 Re: ORDER BY problem
Previous Message Tom Lane 2004-03-01 18:00:06 Re: PostgreSQL insert speed tests