ksqo?

Neil Conway <nconway@klamath.dyndns.org> writes:

The current KSQO code is currently #ifdef'ed out, and the 'ksqo' GUC
variable does nothing. Is there a reason for keeping this code around?
(or conversely, what was the original justification for disabling it?)

I disabled it because I didn't have time to fix it properly when it got
broken by the 7.1 rewrite of UNION/INTERSECT/EXCEPT. I've been waiting
to see whether anyone notices that it's gone ;-). So far the demand for
it has been invisible, so it hasn't gotten fixed. On the other hand
I'm not quite convinced that it never will get fixed, so I haven't
applied the coup de grace.

regards, tom lane

On Wed, 22 May 2002 18:03:07 -0400
"Tom Lane" <tgl@sss.pgh.pa.us> wrote:

Neil Conway <nconway@klamath.dyndns.org> writes:

The current KSQO code is currently #ifdef'ed out, and the 'ksqo' GUC
variable does nothing. Is there a reason for keeping this code around?
(or conversely, what was the original justification for disabling it?)

I disabled it because I didn't have time to fix it properly when it got
broken by the 7.1 rewrite of UNION/INTERSECT/EXCEPT. I've been waiting
to see whether anyone notices that it's gone ;-). So far the demand for
it has been invisible, so it hasn't gotten fixed. On the other hand
I'm not quite convinced that it never will get fixed, so I haven't
applied the coup de grace.

Hmmm... Well, I'll take a look at it, but I'll probably just leave it
be -- since the optimization might actually return invalid results, it
doesn't seem like a very valuable thing to have, IMHO.

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Neil Conway <nconway@klamath.dyndns.org> writes:

Hmmm... Well, I'll take a look at it, but I'll probably just leave it
be -- since the optimization might actually return invalid results, it
doesn't seem like a very valuable thing to have, IMHO.

Yeah, I never cared for the fact that it altered the semantics of the
query, even if only subtly. But I'm hesitant to rip out something that
someone went to the trouble of writing and contributing ...

regards, tom lane

Tom Lane wrote:

Neil Conway <nconway@klamath.dyndns.org> writes:

Hmmm... Well, I'll take a look at it, but I'll probably just leave it
be -- since the optimization might actually return invalid results, it
doesn't seem like a very valuable thing to have, IMHO.

Yeah, I never cared for the fact that it altered the semantics of the
query, even if only subtly. But I'm hesitant to rip out something that
someone went to the trouble of writing and contributing ...

If it does nothing, we certainly should remove it from GUC so people
don't see a meaningless option. We can then keep it in CVS to see if we
want it later.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:

Tom Lane wrote:

Neil Conway <nconway@klamath.dyndns.org> writes:

Hmmm... Well, I'll take a look at it, but I'll probably just leave it
be -- since the optimization might actually return invalid results, it
doesn't seem like a very valuable thing to have, IMHO.

Yeah, I never cared for the fact that it altered the semantics of the
query, even if only subtly. But I'm hesitant to rip out something that
someone went to the trouble of writing and contributing ...

If it does nothing, we certainly should remove it from GUC so people
don't see a meaningless option. We can then keep it in CVS to see if we
want it later.

Here is the email from May 28 discussing the removal of GUC.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026