Re: Bytea/Base64 encoders for libpq - interested?
От | Joe Conway |
---|---|
Тема | Re: Bytea/Base64 encoders for libpq - interested? |
Дата | |
Msg-id | 009701c134f1$3fe799b0$0705a8c0@jecw2k1 обсуждение исходный текст |
Ответ на | Re: Bytea/Base64 encoders for libpq - interested? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Bytea/Base64 encoders for libpq - interested?
Re: Bytea/Base64 encoders for libpq - interested? Re: Bytea/Base64 encoders for libpq - interested? |
Список | pgsql-hackers |
> I don't think adding a datatype just to provide base64 encoding is > a wise approach. The overhead of a new datatype (in the sense of > providing operators/functions for it) will be much more than the > benefit. I think providing encode/decode functions is sufficient... > and we have those already, don't we? > It might be nice to have a PQbyteaEscape or some such function available in the libpq client library so that arbitrary binary could be escaped on the client side and used in a sql statement. I actually wrote this already as an addition to the PHP PostgreSQL extension, but it would make more sense, now that I think about it, for it to be in libpq and called from PHP (or whatever). Comments? On a related note, are there any other bytea functions we should have in the backend before freezing for 7.2? I was thinking it would be nice to have a way to cast bytea into text and vice-versa, so that the normal text functions could be used for things like LIKE and concatenation. Any interest in this? If so, any guidance WRT how it should be implemented? -- Joe
В списке pgsql-hackers по дате отправления: