I am full agreement with proposal. I love it!!
(1) const or constant
(2) cacheable
(3) volatile
P.S.
Tom: My mail doesn't reach you. As an AT&T user, you block my machine's IP
address with the anti-spam blocking. :-(
Tom Lane wrote:
>
> Since I'm about to have to edit pg_proc.h to add a namesp
> FWIW, all the blacklists I use (and 510sg is only the first line of
> defense ;-)) have documentation available about the reasons for listing
> IP blocks. F'r instance, looking up Thomas' IP I get:
...
> But this is getting pretty far off-topic for the PG lists.
I'll guess that the list of rea
On Wed, Apr 03, 2002 at 08:45:03AM -0800, Thomas Lockhart wrote:
> ...
> > I'm not sure I'm the only one, am I?
>
> No, I was also blocked from Tom's mail a while ago. I have a static IP,
> but my ISP's entire block of addresses made it on to the spam list Tom
> uses, and the strategy of the list
Martin Renters <[EMAIL PROTECTED]> writes:
> It is also pretty unreasonable to think that any company is
> going to switch providers because of one blacklist or somehow complain
> to their ISP about the spammers the ISP is hosting without any more
> detail than:
> "Blacklist X says you prov
Peter Eisentraut wrote:
>
> Tom Lane writes:
>
> > mlw <[EMAIL PROTECTED]> writes:
> > > (1) const or constant
> > > (2) cacheable
> > > (3) volatile
> >
> > I was wondering about "const" for case 1, also. I think there is some
> > precedent for using "const" with this meaning in other programm
mlw <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Sorry about that. I like 510sg's dnsbl list precisely because it's
>> aggressive, but sometimes it's too aggressive. I can whitelist you
>> if you have a stable IP address ... is 24.147.138.78 a permanently
>> assigned address, or not?
> I wi
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> That said, I'd like to block some spam myself. I'd rather find a spam
> list which doesn't already have me disallowed however...
In case it makes you feel better: my *own* address was on the 510sg list
for awhile last month. But I still use the list
Tom Lane writes:
> mlw <[EMAIL PROTECTED]> writes:
> > (1) const or constant
> > (2) cacheable
> > (3) volatile
>
> I was wondering about "const" for case 1, also. I think there is some
> precedent for using "const" with this meaning in other programming
> languages.
I think the meaning of "con
...
> I'm not sure I'm the only one, am I?
No, I was also blocked from Tom's mail a while ago. I have a static IP,
but my ISP's entire block of addresses made it on to the spam list Tom
uses, and the strategy of the list maintainers seems to be to maximize
the collateral damage to force me to som
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > Tom: My mail doesn't reach you. As an AT&T user, you block my machine's IP
> > address with the anti-spam blocking. :-(
>
> Sorry about that. I like 510sg's dnsbl list precisely because it's
> aggressive, but sometimes it's too aggressive.
mlw <[EMAIL PROTECTED]> writes:
> (1) const or constant
> (2) cacheable
> (3) volatile
I was wondering about "const" for case 1, also. I think there is some
precedent for using "const" with this meaning in other programming
languages. "volatile" for case 3 seems reasonable.
> Tom: My mail does
I am full agreement with proposal. I love it!!
(1) const or constant
(2) cacheable
(3) volatile
P.S.
Tom: My mail doesn't reach you. As an AT&T user, you block my machine's IP
address with the anti-spam blocking. :-(
---(end of broadcast)---
TIP
On Tue, 02 Apr 2002 23:39:35 -0500
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Well, for one thing, we might want to change the name to the correct
> > spelling "cacheable".
>
> Is that correct?
Apparently, other people are confused as well:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Well, for one thing, we might want to change the name to the correct
> spelling "cacheable".
Is that correct?
I looked in the Oxford English Dictionary, the Random House Dictionary,
and a couple other dictionaries of less substantial heft, and could
On Tue, 2 Apr 2002, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Since I'm about to have to edit pg_proc.h to add a namespace column,
> > I thought this would be a good time to revise the current proiscachable
> > column into the three-way cachability distinction we've discussed
> > before.
Tom Lane writes:
> Since I'm about to have to edit pg_proc.h to add a namespace column,
> I thought this would be a good time to revise the current proiscachable
> column into the three-way cachability distinction we've discussed
> before. But I need some names for the values, and I'm not satisf
* Tom Lane ([EMAIL PROTECTED]) [020402 16:42]:
> Since I'm about to have to edit pg_proc.h to add a namespace column,
> I thought this would be a good time to revise the current proiscachable
> column into the three-way cachability distinction we've discussed
> before. But I need some names for t
Tom Lane wrote:
> BTW, because of MVCC semantics, case 2 covers more ground than you might
> think. We are interested in functions whose values cannot change during
> a single "scan", ie, while the intra-transaction command counter does
> not increment. So functions that do SELECTs are actually
My 2 cents.
Level 1. with (isCachableStatic)
Level 2. with (isCachableDynamic)
Level 3. default
In my mind (isCachable) sounds like level 1
On Tuesday 02 April 2002 03:40 pm, Tom Lane wrote:
> Since I'm about to have to edit pg_proc.h to add a namespace column,
> I thought this would be a good
19 matches
Mail list logo
