Sorry for the pgTAP off-topicness here, hackers. Please feel free to ignore.
On May 17, 2016, at 8:10 AM, Jim Nasby wrote:
> Speaking specifically to is(), what I'd find most useful is if it at least
> hinted that there might be some type shenanigans going on, because
On May 17, 2016, at 7:58 AM, Jim Nasby wrote:
> Probably in an attempt to bypass parse overhead on ingestion.
>
> Possibly because JSONB silently eats duplicated keys while JSON doesn't
> (though in that case even casting to JSONB is probably not what you want).
It’s
On 5/11/16 7:05 PM, David E. Wheeler wrote:
On May 11, 2016, at 10:34 AM, Kevin Grittner 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
On 5/12/16 4:25 PM, David E. Wheeler wrote:
On May 12, 2016, at 12:02 PM, Tom Lane wrote:
Andrew mentions in the extension you pointed to that providing a default
comparison operator would enable people to do UNION, DISTINCT, etc on JSON
columns without thinking about it.
On 05/12/2016 03:02 PM, Tom Lane wrote:
"David E. Wheeler" writes:
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
On May 12, 2016, at 12:02 PM, Tom Lane wrote:
> Andrew mentions in the extension you pointed to that providing a default
> comparison operator would enable people to do UNION, DISTINCT, etc on JSON
> columns without thinking about it. I'm not convinced that "without
>
"David E. Wheeler" writes:
> 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
On May 12, 2016, at 11:19 AM, Fabrízio de Royes Mello
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
On Wed, May 11, 2016 at 9:09 PM, David E. Wheeler
wrote:
>
> On May 11, 2016, at 11:01 AM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> > I know... but you can do that just in case the current behaviour fail
by cathing it with "begin...exception...", so
On May 11, 2016, at 11:01 AM, Fabrízio de Royes Mello
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
On May 11, 2016, at 10:34 AM, Kevin Grittner 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,
On Wed, May 11, 2016 at 2:07 AM, David E. Wheeler
wrote:
>
> On May 10, 2016, at 5:56 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> > Searching for the operator in pg_operator catalog isn't enought?
>
> Seems like overkill, but will do if there’s nothing
On Wed, May 11, 2016 at 12:23 PM, David E. Wheeler
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
On May 11, 2016, at 10:19 AM, Kevin Grittner 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
On Wed, May 11, 2016 at 12:01 PM, David G. Johnston
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
On Wed, May 11, 2016 at 9:54 AM, Robert Haas wrote:
> On Tue, May 10, 2016 at 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
On Tue, May 10, 2016 at 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
On May 10, 2016, at 5:56 PM, Fabrízio de Royes Mello
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
smime.p7s
Description: S/MIME cryptographic signature
On May 10, 2016, at 6:14 PM, Tom Lane 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
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
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",
On Tuesday, May 10, 2016, Euler Taveira 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
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
On Tuesday, May 10, 2016, 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
"David E. Wheeler" 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
Em terça-feira, 10 de maio de 2016, David E. Wheeler
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,
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 ~
27 matches
Mail list logo