Rodolfo Vegas escribió: > Lo que pasa es lo siguiente, al trabajar con la logica difuza se maneja > el concepto de grado de membresía que seria un atributo más aparte de los > que ya tienen, entonces cuando se crea el plan normal el va a tener tantos > Targetentry como atributos tenga mas uno de más que sería el flag, ahora ese > flag no va a tener ningún valor almacenado, por ejemplo cuando el postgre > ejecuta el INTERSECT yo deberia llamar a los valores del Targetentry de la > siguiente manera > DatumGetFloat4(slot_getattr(inputTupleSlot,inputTupleSlot->inputTupleSlot->tts_tupleDescriptor->natts,&isNull)), > inputTupleSlot->tts_tupleDescriptor->natts indica la cantidad de atributos > que hay, pero yo al hacer ese metodo extrae los valores que tiene el flag > que no son nada y porque hace eso porque el targetentry del grado de > membresia lo esta almacenando despues del flag, por eso es que yo quiero > ordenar esos targetentry que es en realidad una lista y colocar todos los > atributos de primero y de ultimo el flag y ahi no tendria ningun problema.
Se me está empezando a ocurrir que poner el grado de membresía como un atributo de la tupla es un error. Quizás deberías ponerlo en otra parte de las estructuras del ejecutor, pero no sabría decirte dónde. Lo que sí sé es que al modificar la lista de targetentry no tendría por qué molestarte la cantidad de tuplas del TupleDescriptor ... Por ejemplo considera que las tuplas pueden venir de algo que no necesariamente es una tabla (por ej. un subselect). Si insistes en meterlo en la tupla, entonces lo que deberías hacer es modificar el TupleDesc para que refleje el hecho de que hay un atributo más. PD: si quieres usar un nombre abreviado, es "Postgres", no "Postgre". -- Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8 "No necesitamos banderas No reconocemos fronteras" (Jorge González) -- TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
