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: | Raw Message | Whole Thread | 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 |