Postgresql que se muere

[Franco Catrin L.]

El mié, 14-07-2010 a las 15:31 -0400, Gonzalo Diaz escribió:
> El 14 de julio de 2010 15:14, Franco Catrin L. <fcatrin en tuxpan.com>escribió:
> 
> > El mar, 13-07-2010 a las 18:14 -0400, Ricardo Munoz escribió:
> > > El 13 de julio de 2010 17:46, Franco Catrin L. <fcatrin en tuxpan.com
> > >escribió:
> > >
> > > > El mar, 13-07-2010 a las 17:28 -0400, Ricardo Munoz escribió:
> > > >
> > > > [...]
> > > >
> > > > > hmm... insisto que ningun motor de base de datos decente deberia
> > retornar
> > > > un
> > > > > mensaje de error de memoria como resultado de un SELECT....
> > > >
> > > >
> > > > Por qué no?
> > > >
> > > > A mi me parece razonable que el motor tire un error de falta de
> > > > memoria... cuando le falta memoria para procesar el select.
> > > >
> > >
> > > eso quiere decir que tendrias que poner mas memoria a tu servidor por
> > cada
> > > n-cantidad de nuevos registros que le agregas a la base de datos? eso no
> > > tiene sentido... y fijate que el error se produjo con un simple SELECT
> > > COUNT()...
> >
> > Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que
> > ocupe cero bytes está lejos aún.
> >
> > Lectura recomendada:
> > http://www.joelonsoftware.com/articles/LeakyAbstractions.html
> >
> > ... y por supuesto, la explicación detallada de Alvaro sobre lo que
> > sucede behind the scenes.
> >
> Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos
> habrán inventado el sistema de excepciones en postgresql?
> 
> Cabe recordar que un SP se puede programar varios lenguajes ajenos.

Eso es lo que se ve por fuera, pero el día en que inventen un sistema de
excepciones que ocupe cero bytes está lejos aún.

Lectura recomendada:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

BTW: Creo que me haré un template para responder estos correos.
-- 
Franco Catrin L. http://www.tuxpan.com/fcatrin
TUXPAN Software S.A.