proposal - urlencode, urldecode support

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

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