On Fri, 20 Feb 2009 20:45:20 +
Sam Mason wrote:
> On Fri, Feb 20, 2009 at 04:51:33PM +0100, Ivan Sergio Borgonovo
> wrote:
> > What I find a bit annoying is politely deal with the error once
> > it is reported back to the application *and* connection and
> > *bandwidth* costs of moving clearl
On Sat, 21 Feb 2009 15:02:55 -0800
Ron Mayer wrote:
> Ivan Sergio Borgonovo wrote:
> > I was wondering if "checks" may have an impact
> > on performances and if pg does some optimisation over them.
> Are you suggesting thee would be a positive or negative impact
> on performance.
> Moving
Ivan Sergio Borgonovo wrote:
> On Fri, 20 Feb 2009 06:50:22 -0800
> David Fetter wrote:
>>> ... moving some of the checks
>>> into the database and away from the application.
>> Since a useful database has *many* applications instead of "the"
>> application, I think this is an excellent move.
>
>
On Fri, Feb 20, 2009 at 04:51:33PM +0100, Ivan Sergio Borgonovo wrote:
> What I find a bit annoying is politely deal with the error once it
> is reported back to the application *and* connection and *bandwidth*
> costs of moving clearly wrong data back and forward.
This sounds a bit like premature
On Fri, Feb 20, 2009 at 06:50:22AM -0800, David Fetter wrote:
> On Thu, Feb 19, 2009 at 11:43:19PM +, Sam Mason wrote:
> > On Tue, Feb 17, 2009 at 09:53:00AM -0800, David Fetter wrote:
> > > user_name TEXT, -- unless length is an integrity constraint, use TEXT
> > > instead of VARCHAR.
> > >
On Fri, 20 Feb 2009 06:50:22 -0800
David Fetter wrote:
> > The reason behind this appears to be moving some of the checks
> > into the database and away from the application.
>
> Since a useful database has *many* applications instead of "the"
> application, I think this is an excellent move. S
On Thu, Feb 19, 2009 at 11:43:19PM +, Sam Mason wrote:
> I was just reading over a reply from David Fetter from a couple of
> days ago; the thread is archived[1] but this question doesn't really
> relate to it much. The a question about how to arrange tables and
> David make the following comm
