Listen / Notify - what to do when the queue is full
in [PgSql]
|
From: Merlin Moncure on 8 Jan 2010 15:04 On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Merlin Moncure <mmoncure(a)gmail.com> writes: >> On Fri, Jan 8, 2010 at 7:48 AM, Joachim Wieland <joe(a)mcknight.de> wrote: >>> - do we need to limit the payload to pure ASCII ? I think yes, we need >>> to. I also think we need to reject other payloads with elog(ERROR...). > >> Just noticed this...don't you mean UTF8? Are we going to force non >> English speaking users to send all payloads in English? > > 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 (if necessary hex/b64 encoded)? I'm just trying to imagine how databases encoded in non ascii superset encodings would use this feature... If we must use ascii, we should probably offer conversion functions to/from text, right? I definitely understand the principle of the utility of laziness, but is this a proper case of simply dumping the problem onto the user? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stefan Kaltenbrunner on 8 Jan 2010 15:11 Andrew Chernow wrote: >> conversion problems in some circumstances - what about bytea (or why >> _do_ we have to limit this to something?). >> > > I agree with bytea. Zero conversions and the most flexible. Payload > encoding/format should be decided by the user. yeah that is exactly why I think they this would be the most flexible option... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Chernow on 8 Jan 2010 15:07 > conversion problems in some circumstances - what about bytea (or why > _do_ we have to limit this to something?). > I agree with bytea. Zero conversions and the most flexible. Payload encoding/format should be decided by the user. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 8 Jan 2010 16:10 Merlin Moncure <mmoncure(a)gmail.com> writes: > On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane <tgl(a)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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Merlin Moncure on 8 Jan 2010 16:23
On Fri, Jan 8, 2010 at 4:10 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Merlin Moncure <mmoncure(a)gmail.com> writes: >> On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane <tgl(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |