Thread: using xmin in a query?
Why does this query succeed:
select count(*) from tablename where xmin = 2
while this query fails:
select count(*) from tablename where xmin != 2
The latter will generate an error message (using 9.0.4, but it does not seem to be version specific):
ERROR: operator does not exist: xid <> integer
LINE 1: select count(*) from tablename where xmin != 2;
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
What cast or comparison operator would work? You cannot cast an xid to an integer, nor can you cast an integer to an xid.
The only way I can get this to work is:
select count(*) from tablename where not xmin = 2
That seems pretty obscure.
--
Mike Nolan
nolan@tssi.com
select count(*) from tablename where xmin = 2
while this query fails:
select count(*) from tablename where xmin != 2
The latter will generate an error message (using 9.0.4, but it does not seem to be version specific):
ERROR: operator does not exist: xid <> integer
LINE 1: select count(*) from tablename where xmin != 2;
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
What cast or comparison operator would work? You cannot cast an xid to an integer, nor can you cast an integer to an xid.
The only way I can get this to work is:
select count(*) from tablename where not xmin = 2
That seems pretty obscure.
--
Mike Nolan
nolan@tssi.com
On 7/28/2011 11:40 AM, Michael Nolan wrote: > Why does this query succeed: > > select count(*) from tablename where xmin = 2 > > while this query fails: > > select count(*) from tablename where xmin != 2 > You probably want <>. select count(*) from tablename where xmin <> 2 -Andy
On Thu, Jul 28, 2011 at 12:23 PM, Andy Colson <andy@squeakycode.net> wrote:
That doesn't work either.
--
Mike Nolan
On 7/28/2011 11:40 AM, Michael Nolan wrote:You probably want <>.Why does this query succeed:
select count(*) from tablename where xmin = 2
while this query fails:
select count(*) from tablename where xmin != 2
That doesn't work either.
--
Mike Nolan
-Andy
select count(*) from tablename where xmin <> 2
On 07/28/2011 03:09 PM, Michael Nolan wrote:
What about select count(*) from tablename where xmin::text::integer != 2;
Regards
Rodrigo
On Thu, Jul 28, 2011 at 12:23 PM, Andy Colson <andy@squeakycode.net> wrote:On 7/28/2011 11:40 AM, Michael Nolan wrote:You probably want <>.Why does this query succeed:
select count(*) from tablename where xmin = 2
while this query fails:
select count(*) from tablename where xmin != 2
That doesn't work either.
What about select count(*) from tablename where xmin::text::integer != 2;
Regards
Rodrigo
Michael Nolan <htfoot@gmail.com> writes: > Why does this query succeed: > select count(*) from tablename where xmin = 2 > while this query fails: > select count(*) from tablename where xmin != 2 It told you why not: > ERROR: operator does not exist: xid <> integer You could do "where not (xmin = 2)", I suppose. regards, tom lane
On Thu, Jul 28, 2011 at 2:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I understand that, Tom, and my original posted did cite 'not xmin = 2' as working.
The parentheses appear to be optional, though in a more complex query they would probably be necessary to make sure it parses properly.
It appears to me that it is doing an implicit cast of the integer '2' into an xid in the first query.
It seems like we're being inconsistent here in allowing 'where xid = integer'
but not allowing 'where xid != integer'.
Michael Nolan <htfoot@gmail.com> writes:It told you why not:
> Why does this query succeed:
> select count(*) from tablename where xmin = 2
> while this query fails:
> select count(*) from tablename where xmin != 2You could do "where not (xmin = 2)", I suppose.
> ERROR: operator does not exist: xid <> integer
I understand that, Tom, and my original posted did cite 'not xmin = 2' as working.
The parentheses appear to be optional, though in a more complex query they would probably be necessary to make sure it parses properly.
It appears to me that it is doing an implicit cast of the integer '2' into an xid in the first query.
It seems like we're being inconsistent here in allowing 'where xid = integer'
but not allowing 'where xid != integer'.
Is there no explicit 'cast to xid' available?
--
Mike Nolan
Michael Nolan <htfoot@gmail.com> writes: > It seems like we're being inconsistent here in allowing 'where xid = > integer' but not allowing 'where xid != integer'. Well, if you look into pg_operator you'll soon find that there are exactly two built-in operators that accept type xid: "=(xid,xid)" and "=(xid,integer)" (where I'd say the latter is just a kluge). There hasn't previously been any demand to flesh it out more than that. Do you have an actual use-case where <> would be helpful, or is this just experimentation? regards, tom lane
On Thu, Jul 28, 2011 at 5:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm not sure yet. I was doing some thinking about ways to do incremental backups
(at least for inserted/updated rows, deleted rows present a different challenge),
and was just doing some simple queries to see what worked and what didn't..
It also appears you cannot group on a column of type xid.
Would adding a <> operator enable that?
--
Mike Nolan
Michael Nolan <htfoot@gmail.com> writes:> It seems like we're being inconsistent here in allowing 'where xid =Well, if you look into pg_operator you'll soon find that there are
> integer' but not allowing 'where xid != integer'.
exactly two built-in operators that accept type xid: "=(xid,xid)" and
"=(xid,integer)" (where I'd say the latter is just a kluge).
There hasn't previously been any demand to flesh it out more than that.
Do you have an actual use-case where <> would be helpful, or is this
just experimentation?
I'm not sure yet. I was doing some thinking about ways to do incremental backups
(at least for inserted/updated rows, deleted rows present a different challenge),
and was just doing some simple queries to see what worked and what didn't..
It also appears you cannot group on a column of type xid.
Would adding a <> operator enable that?
--
Mike Nolan
Michael Nolan <htfoot@gmail.com> writes: > It also appears you cannot group on a column of type xid. You can in 8.4 and up. Previous versions only know how to GROUP BY sortable columns, which requires a btree opclass, which xid doesn't have and really can't have because it doesn't have a linear ordering. There is a hash opclass for it, though, so in versions that know how to GROUP BY using hashing, it'll work. > Would adding a <> operator enable that? No, it's pretty irrelevant ... regards, tom lane
On Thu, Jul 28, 2011 at 5:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
:sigh: I thought I had done all the tests on my 9.0.4 testbed server too. One of
these days I hope to get the production and development servers off 8.2.
I more or less understand why xid types don't have a linear ordering from Robert Hass's tutorial at PGCON11.
So, a <> operator (either xid,xid or xid,integer) would need to be implemented using the hash opclass, correct?
(I don't have a use case for it yet, though.)
OK, thanks for putting up with my noobie questions.
--
Mike Nolan
Michael Nolan <htfoot@gmail.com> writes:> It also appears you cannot group on a column of type xid.You can in 8.4 and up. Previous versions only know how to GROUP BY
sortable columns, which requires a btree opclass, which xid doesn't
have and really can't have because it doesn't have a linear ordering.
There is a hash opclass for it, though, so in versions that know how to
GROUP BY using hashing, it'll work.
:sigh: I thought I had done all the tests on my 9.0.4 testbed server too. One of
these days I hope to get the production and development servers off 8.2.
I more or less understand why xid types don't have a linear ordering from Robert Hass's tutorial at PGCON11.
So, a <> operator (either xid,xid or xid,integer) would need to be implemented using the hash opclass, correct?
(I don't have a use case for it yet, though.)
No, it's pretty irrelevant ...
> Would adding a <> operator enable that?
OK, thanks for putting up with my noobie questions.
--
Mike Nolan
Michael Nolan <htfoot@gmail.com> writes: > So, a <> operator (either xid,xid or xid,integer) would need to be > implemented using the hash opclass, correct? No, it's unrelated to the opclass. It'd be worth marking it as the negator of the equality operator, but otherwise it'd really be unconnected to anything else. regards, tom lane