On Fri, Jan 8, 2010 at 4:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> No, he meant ASCII. Otherwise we're going to have to deal with encoding
>>> conversion issues.
>
>> That seems pretty awkward...instead of forcing an ancient, useless to
>> 90% of the world encoding, why not send bytea
>
> You mean declare the notify parameter as bytea instead of text, and dump
> all encoding conversion issues onto the user? We could do that I guess.
> I'm not convinced that it's either more functional or more convenient to
> use than a parameter that's declared as text and restricted to ASCII.
>
>> If we must use ascii, we should probably offer conversion functions
>> to/from text, right?
>
> There's encode() and decode(), which is what people would wind up using
> quite a lot of the time if we declare the parameter to be bytea.
all good points...IF notify payload can be result of expression so for
non const cases where you are expecting non ascii data you can throw a
quick encode. I had assumed it didn't (wrongly?) because current
notify relname takes a strict literal, so this would work (If the
below works, disregard the rest and I concede ascii is fine):
notify test encode('some_string', 'hex');
A quick look at gram.y changes suggest this wont work if I read it
correctly. How would someone from Japan issue a notify/payload from
the console?
merlin
