Re: OT[extensión con tipo de dato email]

El 11/05/2013 0:58, Alvaro Herrera escribió:
> anthony escribió:
>> Hola colegas les escribo para dejarles a su consideración una
>> extensión que desarrollamos acá que consiste en un tipo de dato
>> nuevo email, quisiera que si tienen un tiempo la probaran y nos
>> ayudaran a solucionar posibles bugs, esta es la
>> URL: http://pgxn.org/dist/email/0.1.0/
> Bah, lo primero que me imaginé es que el tipo servía para almacenar un
> email, es decir un correo completo (encabezado, cuerpo, attachments,
> etc) pero realmente lo que hace es almacenar una dirección.
>
> Honestamente creo que tu tipo es demasiado simplista, sólo puede
> almacenar la dirección en crudo. Para que fuera interesante desde mi
> punto de vista, tendrías que soportar el formato completo:
> "Nombre y demás" <la(dot)direccion(at)propiamente(dot)tal>
>
> Esto aparece en https://tools.ietf.org/html/rfc5322#section-3.4
>
Bueno honestamente, esperé comentarios como estos(fuertes y duros), para
la primera actividad de hobby para crear tipos de datos para postgresql,
después de haber leído en la documentación esta sección, para lo cual
seleccionamos un tipo que consideramos simple, además siempre es bueno
tener la opinión de los expertos en estos temas, la idea siempre fue
almacenar simplemente la dirección de correo electrónico validada y
esto pudiera quitar responsabilidad a algunas partes de las app que lo
hagan, como lo hace el json o el xml cuando los insertan en la BD, tal
vez no sea ese el nombre de la extensión y pudiera decirse algo así como
"emailaddress", entiendo lo que me quiere decir con almacenar esto
("Nombre y demás" <la(dot)direccion(at)propiamente(dot)tal> ), pero la coloque en
un link de los links que me sugirió (http://isemail.info/) y me dice
que no es válida, aunque pudieramos valorarla y poder almacenarla en ese
formato.
> Ahora, dejando eso de lado, suponiendo que sólo quieres almacenar
> direcciones "en crudo" del tipo que se puede poner en el "envelope" de
> un correo (en vez de en el To: o Cc:, que son las que describe el
> párrafo de arriba), entonces de todas maneras tu tipo se queda corto; la
> validación con una regex es un tema que ha sido bien debatido y no se
> considera buena idea. Por ej. dale una leída a
> http://blog.dominicsayers.com/category/email-address-validation/
> https://en.wikipedia.org/wiki/Email_address
Realmente consideramos más costoso hacer la validación a "mano" que
utilizando "regex", lo cual es bien útil, pero lo volveremos a valorar,
la expresión regular que ponemos en el código tal vez no abarque todas
pero se puede mejorar, creemos, vamos a volver a revisar a ver si
logramos una más completa o lo realizamos a "mano"(a mano aquí en Cuba
significa algo así como: hacerlo por nuestros propios medio sin utilizar
bibliotecas extra o algo útil para hacerlo)

> Principalmente considera que una @ puede aparecer en la "parte local",
> siempre y cuando esté entre comillas, o sea "alv(at)ro"@example.com sería
> una dirección válida, aún cuando tu código (creo que) presentaría varios
> errores al recibirla.
humm, nunca la había visto una dirección así, es bien extraña , pero
bueno válida al fin, la tendremos en cuenta también.
gracias por : https://tools.ietf.org/html/rfc2822 y
https://tools.ietf.org/html/rfc6531
>
> Un tercer tema es el almacenamiento. No leí tu código en detalle pero
> me parece que tomas el string y lo almacenas tal cual; luego para buscar
> la parte local y el dominio tienes que leer todo y volver a procesar.
> Me permito sugerir que proceses una vez durante la función input, y
> guardes el resultado del procesamiento. Por ej. podrías guardar
>
> 8alvherrealvh.no-ip.org
> donde primero se almacena el largo de la parte local, luego la parte
> local, y luego el dominio hasta el final del valor. Entonces puedes
> obtener la parte local leyendo el largo y a continuación la cantidad de
> bytes del largo; y puedes obtener el dominio leyendo el largo, saltando
> esa cantidad de bytes, y luego leyendo hasta el final del dato. No
> necesitas buscar una @ para obtener ninguno de los dos, por lo tanto la
> parte local podría contener una y no te causaría ningún problema.
buena sugerencia, me gusta para evitar sobre todo el tema de la búsqueda
de la "@"

>
> ¿cuál es el propósito de tener tanto get_user como getuser?
>
Bueno en realidad hicimos primero get_user en plpgsql y luego getuser en
C, para probar simplemente, pudiéramos dejar solamente la de C,
nada de esto quita que lo que comenzó como un hobby probando hacer cosas
para el gestor se convierta en un aporte útil futuro para algún proyecto
que lo necesite o tal vez para el proyecto postgresql en si mismo.

Saludos y Gracias por sus comentarios y sugerencias.

http://www.uci.cu