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 I've run
> across somethi
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 also when you’d want text
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 problems with IS DI
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. I'm not convinced th
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 want why aren't they usi
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
> thinking about it" is a goo
"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 the first place?â
> S
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 work of creating such opera
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 you'll minimize the looking
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 this issue would go away fo
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, except for the
situ
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 else.
>
I know... but
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 same storage value. See
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 comparing the plain text of
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 '(1,1)(2,2)'::box = '(-4.5,1000)(-2
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 3 (1 for hash) [equality]
> where
> > the left and r
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 type in question.
The core sy
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
'foo'::citext = 'FOO':ci
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 thought
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
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 from" ~ "<>" which is
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
> interface at the SQL
"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 you're coercing both one in
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, anyelement, TEXT )
> RETURNS
26 matches
Mail list logo