El 14 de julio de 2010 15:14, Franco Catrin L. <[email protected]>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. <[email protected] > >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. > > -- > Franco Catrin L. http://www.tuxpan.com/fcatrin > TUXPAN Software S.A. > > 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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Atentamente, Gonzalo Díaz Cruz Estudiante Ingeniería de Ejecución en Computación e Informática Universidad de Santiago de Chile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://blog.gon.cl/ http://twitter.com/sir_gon http://flickr.com/photos/sir_gon
