Does Type Have = Operator?
Hackers,
pgTAP has a function that compares two values of a given type, which it uses for comparing column defaults. It looks like this:
CREATE OR REPLACE FUNCTION _def_is( TEXT, TEXT, anyelement, TEXT )
RETURNS TEXT AS $$
DECLARE
thing text;
BEGIN
IF $1 ~ '^[^'']+[(]' THEN
-- It's a functional default.
RETURN is( $1, $3, $4 );
END IF;
EXECUTE 'SELECT is('
|| COALESCE($1, 'NULL' || '::' || $2) || '::' || $2 || ', '
|| COALESCE(quote_literal($3), 'NULL') || '::' || $2 || ', '
|| COALESCE(quote_literal($4), 'NULL')
|| ')' INTO thing;
RETURN thing;
END;
$$ LANGUAGE plpgsql;
The is() function does an IS DISTINCT FROM to compare the two values passed to it. This has been working pretty well for years, but one place it doesn’t work is with JSON values. I get:
LINE 1: SELECT NOT $1 IS DISTINCT FROM $2
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
QUERY: SELECT NOT $1 IS DISTINCT FROM $2
This makes sense, of course, and I could fix it by comparing text values instead of json values when the values are JSON. But of course the lack of a = operator is not limited to JSON. So I’m wondering if there’s an interface at the SQL level to tell me whether a type has an = operator? That way I could always use text values in those situations.
Thanks,
David
Attachments:
smime.p7sapplication/pkcs7-signature; name=smime.p7sDownload
Em terça-feira, 10 de maio de 2016, David E. Wheeler <david@justatheory.com>
escreveu:
Hackers,
pgTAP has a function that compares two values of a given type, which it
uses for comparing column defaults. It looks like this:CREATE OR REPLACE FUNCTION _def_is( TEXT, TEXT, anyelement, TEXT )
RETURNS TEXT AS $$
DECLARE
thing text;
BEGIN
IF $1 ~ '^[^'']+[(]' THEN
-- It's a functional default.
RETURN is( $1, $3, $4 );
END IF;EXECUTE 'SELECT is('
|| COALESCE($1, 'NULL' || '::' || $2) || '::' || $2 || ',
'
|| COALESCE(quote_literal($3), 'NULL') || '::' || $2 ||
', '
|| COALESCE(quote_literal($4), 'NULL')
|| ')' INTO thing;
RETURN thing;
END;
$$ LANGUAGE plpgsql;The is() function does an IS DISTINCT FROM to compare the two values
passed to it. This has been working pretty well for years, but one place it
doesn’t work is with JSON values. I get:LINE 1: SELECT NOT $1 IS DISTINCT FROM $2
^
HINT: No operator matches the given name and argument type(s). You
might need to add explicit type casts.
QUERY: SELECT NOT $1 IS DISTINCT FROM $2This makes sense, of course, and I could fix it by comparing text values
instead of json values when the values are JSON. But of course the lack of
a = operator is not limited to JSON. So I’m wondering if there’s an
interface at the SQL level to tell me whether a type has an = operator?
That way I could always use text values in those situations.
Searching for the operator in pg_operator catalog isn't enought?
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Show quoted text
Timbira: http://www.timbira.com.br
Blog: http://fabriziomello.github.io
Linkedin: http://br.linkedin.com/in/fabriziomello
Twitter: http://twitter.com/fabriziomello
Github: http://github.com/fabriziomello
"David E. Wheeler" <david@justatheory.com> writes:
pgTAP has a function that compares two values of a given type, which it uses for comparing column defaults. It looks like this:
CREATE OR REPLACE FUNCTION _def_is( TEXT, TEXT, anyelement, TEXT )
RETURNS TEXT AS $$
Given that you're coercing both one input value and the result to text,
I don't understand why you don't just compare the text representations.
I'm also not very clear on what you mean by "comparing column defaults".
A column default is an expression (in the general case anyway), not just
a value of the type.
Maybe if you'd shown us the is() function, as well as a typical usage
of _def_is(), this would be less opaque.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tuesday, May 10, 2016, David E. Wheeler <david@justatheory.com> wrote:
This makes sense, of course, and I could fix it by comparing text values
instead of json values when the values are JSON. But of course the lack of
a = operator is not limited to JSON. So I’m wondering if there’s an
interface at the SQL level to tell me whether a type has an = operator?
That way I could always use text values in those situations.
http://www.postgresql.org/docs/9.5/interactive/catalog-pg-amop.html
http://www.postgresql.org/docs/9.5/interactive/xindex.html
Brute force: you'd have to query pg_amop and note the absence of a row with
a btree (maybe hash too...) family strategy 3 (1 for hash)
[equality] where the left and right types are the same and match the type
in question.
There is likely more to it - though absence is pretty much a given I'd be
concerned about false negatives due to ignoring other factors like
"amoppurpose".
In theory you should be able to trade off convenience for correctness by
calling:
to_regoperator('=(type,type)')
But I've never tried it and it assumes that = is the equality operator and
that its presence is sufficient. I'm also guessing on the text type name
syntax.
http://www.postgresql.org/docs/9.5/interactive/functions-info.html
This option is a young one from what I remember.
David J.
On 10-05-2016 21:12, David E. Wheeler wrote:
This makes sense, of course, and I could fix it by comparing text
values instead of json values when the values are JSON. But of course
the lack of a = operator is not limited to JSON. So I’m wondering if
there’s an interface at the SQL level to tell me whether a type has
an = operator? That way I could always use text values in those
situations.
There isn't an equality notation at catalogs. You could try "SELECT
oprname FROM pg_operator WHERE oprcode::text ~ 'eq'" but it is too
fragile. You could also try oprname, oprrest or oprjoin but the result
is worse than the former solution. You definitely need a hack.
Also, IS DISTINCT FROM is an alias for = operator per standard IIRC.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tuesday, May 10, 2016, Euler Taveira <euler@timbira.com.br> wrote:
Also, IS DISTINCT FROM is an alias for = operator per standard IIRC.
Technically "is not distinct from" would be more correct. Alias implies
exact while in the presence of nulls the two behave differently.
"is distinct from" ~ "<>" which is the canonical form (alias) for "!="
http://www.postgresql.org/docs/9.5/interactive/functions-comparison.html
David J.
On 10-05-2016 22:28, David G. Johnston wrote:
Technically "is not distinct from" would be more correct.
Ooops. Fat fingered the statement. Also, forgot to consider null case.
euler=# \pset null 'NULL'
Null display is "NULL".
euler=# select x.a, y.b, x.a IS NOT DISTINCT FROM y.b AS "INDF", x.a =
y.b AS "=" FROM (VALUES (3), (6), (NULL)) AS x (a), (VALUES (3), (6),
(NULL)) AS y (b);
a | b | INDF | =
------+------+------+------
3 | 3 | t | t
3 | 6 | f | f
3 | NULL | f | NULL
6 | 3 | f | f
6 | 6 | t | t
6 | NULL | f | NULL
NULL | 3 | f | NULL
NULL | 6 | f | NULL
NULL | NULL | t | NULL
(9 rows)
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 5/10/16 9:16 PM, David G. Johnston wrote:
Brute force: you'd have to query pg_amop and note the absence of a row
with a btree (maybe hash too...) family strategy 3 (1 for hash)
[equality] where the left and right types are the same and match the
type in question.
While these are good thoughts, the implementation of DISTINCT actually
looks for an operator that is literally named "=".
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On May 10, 2016, at 6:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Given that you're coercing both one input value and the result to text,
I don't understand why you don't just compare the text representations.
Because sometimes the text is not equal when the casted text is. Consider
'foo'::citext = 'FOO':citext
I'm also not very clear on what you mean by "comparing column defaults".
A column default is an expression (in the general case anyway), not just
a value of the type.
Yeah, the pgTAP column_default_is() function takes a string representation of an expression.
Maybe if you'd shown us the is() function, as well as a typical usage
of _def_is(), this would be less opaque.
Here’s is():
CREATE OR REPLACE FUNCTION is (anyelement, anyelement, text)
RETURNS TEXT AS $$
DECLARE
result BOOLEAN;
output TEXT;
BEGIN
-- Would prefer $1 IS NOT DISTINCT FROM, but that's not supported by 8.1.
result := NOT $1 IS DISTINCT FROM $2;
output := ok( result, $3 );
RETURN output || CASE result WHEN TRUE THEN '' ELSE E'\n' || diag(
' have: ' || CASE WHEN $1 IS NULL THEN 'NULL' ELSE $1::text END ||
E'\n want: ' || CASE WHEN $2 IS NULL THEN 'NULL' ELSE $2::text END
) END;
END;
$$ LANGUAGE plpgsql;
_def_is() is called by another function, which effectively is:
CREATE OR REPLACE FUNCTION _cdi ( NAME, NAME, NAME, anyelement, TEXT )
RETURNS TEXT AS $$
BEGIN
RETURN _def_is(
pg_catalog.pg_get_expr(d.adbin, d.adrelid),
pg_catalog.format_type(a.atttypid, a.atttypmod),
$4, $5
)
FROM pg_catalog.pg_namespace n, pg_catalog.pg_class c, pg_catalog.pg_attribute a,
pg_catalog.pg_attrdef d
WHERE n.oid = c.relnamespace
AND c.oid = a.attrelid
AND a.atthasdef
AND a.attrelid = d.adrelid
AND a.attnum = d.adnum
AND n.nspname = $1
AND c.relname = $2
AND a.attnum > 0
AND NOT a.attisdropped
AND a.attname = $3;
END;
$$ LANGUAGE plpgsql;
That function si called like this:
_cdi( :schema, :table, :column, :default, :description );
Best,
David
Attachments:
smime.p7sapplication/pkcs7-signature; name=smime.p7sDownload
On May 10, 2016, at 5:56 PM, Fabrízio de Royes Mello <fabriziomello@gmail.com> wrote:
Searching for the operator in pg_operator catalog isn't enought?
Seems like overkill, but will do if there’s nothing else.
Best,
David
Attachments:
smime.p7sapplication/pkcs7-signature; name=smime.p7sDownload
On Tue, May 10, 2016 at 9:16 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
Brute force: you'd have to query pg_amop and note the absence of a row with
a btree (maybe hash too...) family strategy 3 (1 for hash) [equality] where
the left and right types are the same and match the type in question.
The core system uses this kind of thing to find equality operators in
a number of cases.
We often assume that the operator which implements equality for the
type's default btree operator class is the canonical one for some
purpose. Ditto for the default hash operator class.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 11, 2016 at 9:54 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, May 10, 2016 at 9:16 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:Brute force: you'd have to query pg_amop and note the absence of a row
with
a btree (maybe hash too...) family strategy 3 (1 for hash) [equality]
where
the left and right types are the same and match the type in question.
The core system uses this kind of thing to find equality operators in
a number of cases.We often assume that the operator which implements equality for the
type's default btree operator class is the canonical one for some
purpose. Ditto for the default hash operator class.
Yeah, the user-facing documentation covers it pretty deeply if not in one
central location.
But apparently the core system also uses the fact that "=", if present, is
an equality operator and, less so, that no other operator is expected
to be used for equality.
I suspect that such an expectation is not enforced though - e.g., someone
could define "==" to mean equality if they so choose (the lesser
property). Its hard to imagine defining "=" to mean something different in
logic, though, without intentionally trying to be cryptic.
David J.
On Wed, May 11, 2016 at 12:01 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
Its hard to imagine defining "=" to mean something different in logic,
though, without intentionally trying to be cryptic.
As long as you don't assume too much about *what* is equal.
test=# select '(1,1)(2,2)'::box = '(-4.5,1000)(-2.5,1000.5)'::box;
?column?
----------
t
(1 row)
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On May 11, 2016, at 10:19 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
As long as you don't assume too much about *what* is equal.
test=# select '(1,1)(2,2)'::box = '(-4.5,1000)(-2.5,1000.5)'::box;
?column?
----------
t
(1 row)
Oh, well crap. Maybe I’d be better off just comparing the plain text of the expressions as Tom suggested.
David
Attachments:
smime.p7sapplication/pkcs7-signature; name=smime.p7sDownload
On Wed, May 11, 2016 at 12:23 PM, David E. Wheeler
<david@justatheory.com> wrote:
Oh, well crap. Maybe I’d be better off just comparing the plain
text of the expressions as Tom suggested.
At the other extreme are the row comparison operators that only
consider values equal if they have the same storage value. See the
last paragraph of:
http://www.postgresql.org/docs/9.5/static/functions-comparisons.html#COMPOSITE-TYPE-COMPARISON
| To support matching of rows which include elements without a
| default B-tree operator class, the following operators are
| defined for composite type comparison: *=, *<>, *<, *<=, *>, and
| *>=. These operators compare the internal binary representation
| of the two rows. Two rows might have a different binary
| representation even though comparisons of the two rows with the
| equality operator is true. The ordering of rows under these
| comparison operators is deterministic but not otherwise
| meaningful. These operators are used internally for materialized
| views and might be useful for other specialized purposes such as
| replication but are not intended to be generally useful for
| writing queries.
I'm not clear enough on your intended usage to know whether these
operators are a good fit, but they are sitting there waiting to be
used if they do fit.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 11, 2016 at 2:07 AM, David E. Wheeler <david@justatheory.com>
wrote:
On May 10, 2016, at 5:56 PM, Fabrízio de Royes Mello <
fabriziomello@gmail.com> wrote:
Searching for the operator in pg_operator catalog isn't enought?
Seems like overkill, but will do if there’s nothing else.
I know... but you can do that just in case the current behaviour fail by
cathing it with "begin...exception...", so you'll minimize the looking for
process on catalog.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Show quoted text
Timbira: http://www.timbira.com.br
Blog: http://fabriziomello.github.io
Linkedin: http://br.linkedin.com/in/fabriziomello
Twitter: http://twitter.com/fabriziomello
Github: http://github.com/fabriziomello
On May 11, 2016, at 10:34 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
I'm not clear enough on your intended usage to know whether these
operators are a good fit, but they are sitting there waiting to be
used if they do fit.
Huh. I haven’t had any problems with IS DISTINCT FROM for rows, except for the situation in which a failure is thrown because the types vary, say between TEXT and CITEXT. That can drive the tester crazy, since it says something like:
Results differ beginning at row 3:
have: (44,Anna)
want: (44,Anna)
But overall I think that’s okay; the tester really does want to make sure the type is correct.
Thanks,
David
Attachments:
smime.p7sapplication/pkcs7-signature; name=smime.p7sDownload
On May 11, 2016, at 11:01 AM, Fabrízio de Royes Mello <fabriziomello@gmail.com> wrote:
I know... but you can do that just in case the current behaviour fail by cathing it with "begin...exception...", so you'll minimize the looking for process on catalog.
Yeah, I guess. Honestly 90% of this issue would go away for me if there was a `json = json` operator. I know there are a couple different ways to interpret JSON equality, though.
David
Attachments:
smime.p7sapplication/pkcs7-signature; name=smime.p7sDownload
On Wed, May 11, 2016 at 9:09 PM, David E. Wheeler <david@justatheory.com>
wrote:
On May 11, 2016, at 11:01 AM, Fabrízio de Royes Mello <
fabriziomello@gmail.com> wrote:
I know... but you can do that just in case the current behaviour fail
by cathing it with "begin...exception...", so you'll minimize the looking
for process on catalog.
Yeah, I guess. Honestly 90% of this issue would go away for me if there
was a `json = json` operator. I know there are a couple different ways to
interpret JSON equality, though.
Yeah.. it's ugly but you can do something like that:
CREATE OR REPLACE FUNCTION json_equals_to_json(first JSON, second JSON)
RETURNS boolean AS
$$
BEGIN
RETURN first::TEXT IS NOT DISTINCT FROM second::TEXT;
END
$$
LANGUAGE plpgsql IMMUTABLE;
CREATE OPERATOR = (
LEFTARG = json,
RIGHTARG = json,
PROCEDURE = json_equals_to_json
);
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Show quoted text
Timbira: http://www.timbira.com.br
Blog: http://fabriziomello.github.io
Linkedin: http://br.linkedin.com/in/fabriziomello
Twitter: http://twitter.com/fabriziomello
Github: http://github.com/fabriziomello
On May 12, 2016, at 11:19 AM, Fabrízio de Royes Mello <fabriziomello@gmail.com> wrote:
Yeah.. it's ugly but you can do something like that:
I could, but I won’t, since this is pgTAP and users of the library might have defined their own json operators.
Andrew Dunstan has done the yeoman’s work of creating such operators, BTW:
https://bitbucket.org/adunstan/jsoncmp
Some might argue that it ought to compare JSON objects, effectively be the equivalent of ::jsonb = ::jsonb, rather than ::text = ::text. But as Andrew points out to me offlist, “if that's what they want why aren't they using jsonb in the first place?”
So I think that, up to the introduction of JSONB, it was important not to side one way or the other and put a JSON = operator in core. But now what we have JSONB, perhaps it makes sense to finally take sides and intoduce JSON = that does plain text comparison. Thoughts?
Best,
David
