Gregory Stark <[EMAIL PROTECTED]> writes:
> I've thought further about this and I believe the problem is simpler than we
> were thinking previously. All we need is one boolean flag on the equality
> operator for the data type (or perhaps it would be more convenient to have it
> on the operator clas
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> In a thread in July last year, I raised the possibility of transforming
> a query to allow functional indexes to be utilised automatically.
> http://archives.postgresql.org/pgsql-hackers/2006-07/msg00323.php
>
> This idea can work and has many benefits,
On Fri, 2007-01-26 at 10:58 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > If there's clear benefit and a clear way forward, then we might just be
> > OK for 8.3. If not, I'll put this back on the shelf again in favour of
> > other ideas.
>
> I think this is still a long wa
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> If there's clear benefit and a clear way forward, then we might just be
> OK for 8.3. If not, I'll put this back on the shelf again in favour of
> other ideas.
I think this is still a long way off, and there are probably more useful
things to work on for
On Thu, 2007-01-25 at 16:20 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > A simpler, alternate proposal is to allow the user to specify whether a
> > functional index is transformable or not using CREATE or ALTER INDEX,
> > with a default of not transformable. That then lea
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> A simpler, alternate proposal is to allow the user to specify whether a
> functional index is transformable or not using CREATE or ALTER INDEX,
> with a default of not transformable. That then leaves the responsibility
> for specifying this with the user,
> There is a problem of implication here, AFAICS:
> When a user SQL asks
> WHERE col1 = 7
> which equality level is meant when several exist?
Well, the operator must be unique, so there is no problem.
Unique in the sense that an operator with the same name ('=' in this
case)
and argument t
On Wed, 2006-07-12 at 22:34 -0400, Tom Lane wrote:
> More generally, I don't believe in hacks that only work for a small
> number of built-in types: to me, that's prima facie evidence that you
> haven't thought the problem through.
I agree an attempt at a simple definition of the required functio
> > > - add a new boolean to pg_operator to allow us to define which
> > > operators offer true equality ...
> >
> > This would be useful for other purposes too, as we keep coming up
> > against "what's the equality operator for this datatype" problems.
> > However, the restriction to "true" eq
Simon Riggs <[EMAIL PROTECTED]> writes:
> Normally, I would not suggest that we do things only for certain data
> types only. In this case however, it seems that the reason it would work
> only for INTEGER and TEXT data types is that they are simple atomic
> datatypes that have the required propert
On Tue, 2006-07-11 at 17:31 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > ...
> > - add a new boolean to pg_operator to allow us to define which operators
> > offer true equality
> > ...
>
> This would be useful for other purposes too, as we keep coming up
> against "what's
Am Dienstag, 11. Juli 2006 23:31 schrieb Tom Lane:
> We could invent some more-complex concept involving "well, this is
> equality, but there are some functions for which f(x) might differ
> from f(y) anyway" and then mark the presumably-few functions that
> could produce divergent results --- exam
Simon Riggs <[EMAIL PROTECTED]> writes:
> ...
> - add a new boolean to pg_operator to allow us to define which operators
> offer true equality
> ...
This would be useful for other purposes too, as we keep coming up
against "what's the equality operator for this datatype" problems.
However, the res
13 matches
Mail list logo
