Thread: proposal - urlencode, urldecode support
Hello what do you think about enhancing encode, decode functions for support of mentioned code? Regards Pavel Stehule
On Apr 25, 2012, at 13:54, Pavel Stehule wrote: > what do you think about enhancing encode, decode functions for support > of mentioned code? Sounds like a great idea for a PGXN module. Michael Glaesemann grzm seespotcode net
2012/4/25 Michael Glaesemann <grzm@seespotcode.net>: > > On Apr 25, 2012, at 13:54, Pavel Stehule wrote: > >> what do you think about enhancing encode, decode functions for support >> of mentioned code? > > Sounds like a great idea for a PGXN module. it is one variant - but with support some web technologies - XML, JSON, I prefer this in core. Urlcode is one the most used code on world now - implementation is simple - and it can be well integrated with decode, encode functions. Regards Pavel > > Michael Glaesemann > grzm seespotcode net > > >
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2012/4/25 Michael Glaesemann <grzm@seespotcode.net>:
>> Sounds like a great idea for a PGXN module.
> it is one variant - but with support some web technologies - XML,
> JSON, I prefer this in core. Urlcode is one the most used code on
> world now - implementation is simple - and it can be well integrated
> with decode, encode functions.
Embedding that in encode/decode sounds to me like a pretty horrid idea,
actually, unless I misunderstand what you are talking about. URL
encoding is a text-to-text transformation, no? If so, it doesn't fit
into encode/decode, which presume a binary (bytea) decoded form. People
would be needing to do entirely bogus text/bytea coercions to use
such an implementation.
Ergo, this needs to be a separate function, and so the argument for
putting it in core seems a bit weak to me. The net field demand for
the feature, so far, has been zero.
regards, tom lane
On Wed, Apr 25, 2012 at 02:41:19PM -0400, Tom Lane wrote: > Pavel Stehule <pavel.stehule@gmail.com> writes: > > 2012/4/25 Michael Glaesemann <grzm@seespotcode.net>: > >> Sounds like a great idea for a PGXN module. > > > it is one variant - but with support some web technologies - XML, > > JSON, I prefer this in core. Urlcode is one the most used code on > > world now - implementation is simple - and it can be well integrated > > with decode, encode functions. > > Embedding that in encode/decode sounds to me like a pretty horrid idea, > actually, unless I misunderstand what you are talking about. URL > encoding is a text-to-text transformation, no? If so, it doesn't fit > into encode/decode, which presume a binary (bytea) decoded form. People > would be needing to do entirely bogus text/bytea coercions to use > such an implementation. I don't understand the actual proposal here, but urlencoding encodes octets as quoted us-ascii. So, its not really text to text, but bytes to US-ASCII and US-ASCII to bytes. AIUI, a unicode character has no well specified urlencoding. A utf-8 encoded unicode character can be said to have an urlencoding since we can come up a stream of octets to urlencode. Garick
2012/4/25 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> 2012/4/25 Michael Glaesemann <grzm@seespotcode.net>: >>> Sounds like a great idea for a PGXN module. > >> it is one variant - but with support some web technologies - XML, >> JSON, I prefer this in core. Urlcode is one the most used code on >> world now - implementation is simple - and it can be well integrated >> with decode, encode functions. > > Embedding that in encode/decode sounds to me like a pretty horrid idea, > actually, unless I misunderstand what you are talking about. URL > encoding is a text-to-text transformation, no? If so, it doesn't fit > into encode/decode, which presume a binary (bytea) decoded form. People > would be needing to do entirely bogus text/bytea coercions to use > such an implementation. A motivation for this proposal is JSON. I found lot of situation where content of some internet data was was encoded in this code. > > Ergo, this needs to be a separate function, and so the argument for > putting it in core seems a bit weak to me. The net field demand for > the feature, so far, has been zero. > ook - it can be implemented as independently or as part of convert_from, convert_to function. Regards Pavel > regards, tom lane