| From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
|---|---|
| To: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Notify enhancement |
| Date: | 2006-12-04 00:36:49 |
| Message-ID: | 1955.24.211.165.134.1165192609.squirrel@www.dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Sabino Mullane wrote:
>
> Tom Lane asked:
>
>> What "relation constraint"? They can be any identifier you want.
>
> To clarify, it would be nice to use any arbitrary string (perhaps up
> to NAMEDATALEN), rather than bumping into the rules for valid identifiers:
>
> LISTEN notify.name.like.this;
>
> LISTEN table.mutation;
>
> It would also make things like this act more intuitively:
>
> LISTEN nosuchschema.abc;
>
> NOTIFY foo.bar.abc;
>
If it's going to be an arbitrary string it will have to be single quoted,
like other string literals, and unlike identifiers. But I honestly can't
see why we would introduce such an unnecessary backwards incompatibility.
You can use $ as a delimiter if you want some sort of hierarchy of events,
e.g.
LISTEN foo$bar;
Incidentally, I think we will also need to limit the length of the message
string if we're going to store this in shared memory. I'm currently
thinking of NAMEDATALEN per message, but I am open to argument.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-12-04 01:49:04 | Re: Notify enhancement |
| Previous Message | Greg Sabino Mullane | 2006-12-04 00:06:04 | Re: Notify enhancement |