Hey Joel,
+ oprresult = DatumGetBool(FunctionCallInvoke(locfcinfo));
> -+ if (oprresult)
> ++ if (!locfcinfo->isnull && oprresult)
> + return true;
> + }
>
> Is checking !locfcinfo->isnull due to something new in v2,
> or what is just a correction for a problem also in v1?
>
The “!locfcinfo->isnul
Hey Joel,
test opr_sanity ... FAILED
>
> AND binary_coercible(p2.opcintype, p1.amoplefttype));
> amopfamily | amopstrategy | amopopr
> +--+-
> -(0 rows)
> + 2745 |5 |6105
> +(1 row)
>
> -- Operators that
Hey Joel,
I will now proceed with the review of fk_arrays_elem_v2 as well.
>
Great work!!
/Mark
>
Hello Justin,
It doesn't just rebase: it also removes the test which was failing on
> windows
> CI:
>
My apologies, I didn’t include it in the changelog since this is not a code
change, just wanted to see if any other test would fail on the windows CI
I think the SELECT, when it works, is actuall
>
>
> This still fails for CI (windows) and me (linux)
>
> Can you provide more information about your Linux platform? So I may test
> the errors for myself?
>
Seems the new tests fails every CI. That’s good honestly, that we found
this problem.
The `arrays` regression test extensively test the ne
this patch?
Best Regards,
Mark Rofail
On Tue, 19 Jan 2021 at 2:22 PM Joel Jacobson wrote:
> On Mon, Jan 18, 2021, at 18:23, Tom Lane wrote:
> > I realized that there's a stronger roadblock for
> > treating catalog interrelationships as SQL foreign keys. Namely,
> &
I'll post tomorrow the latest rebased patch with a summary of the issues.
Let's continue this in the foreign key array thread, as to not clutter this
thread.
Regards, Mark Rofail.
On Tue, Jan 19, 2021, 11:00 PM Joel Jacobson wrote:
> On Tue, Jan 19, 2021, at 18:25, Mark Rofail w
ent issue blocked me from doing so.
Reviews and suggestions are most welcome, @Joel Jacobson
please
review and test as previously agreed.
/Mark
On Tue, Oct 2, 2018 at 7:13 AM Michael Paquier wrote:
> On Sat, Aug 11, 2018 at 05:20:57AM +0200, Mark Rofail wrote:
> > I am still having probl
Hello Joel,
On Sun, Jan 24, 2021 at 12:11 PM Joel Jacobson wrote:
> HINT: No operator matches the given name and argument types. You might
> need to add explicit type casts.
> QUERY: SELECT 1 WHERE (SELECT pg_catalog.count(DISTINCT y) FROM
> pg_catalog.unnest($1) y) OPERATOR(pg_catalog.=) (SEL
Hello Joel,
UPDATE catalog_clone.pg_index SET indkey = '1 2 12345'::int2vector WHERE
> indexrelid = 2837;
> ERROR: operator does not exist: int2vector pg_catalog.@> smallint[]
> LINE 1: ...WHERE "attrelid" OPERATOR(pg_catalog.=) $1 AND $2 OPERATOR(p...
>
In your example, you are using the notati
Hello Joel,
Thank you for your kind words and happy that you benefited from this patch.
We simply assert that the update/delete method used is supported currently
only "NO ACTION" and "RESTRICT", this can be extended in future patches
without rework, just extra logic.
Please don't hesitate to give
p the good work testing this patch.
/Mark
On Wed, Jan 27, 2021 at 5:11 AM Joel Jacobson wrote:
> On Tue, Jan 26, 2021, at 12:59, Mark Rofail wrote:
> > Please don't hesitate to give your feedback.
>
> The error message for insert or update violations looks fine:
>
> U
>
>
> Hey Joel,
I apologize for my rash response, I did not quite understand your example
> at first, it appears the UPDATE statement is neither over the
> referencing nor the referenced columns
>
The v14 fixed the issue where an error would occur by an update statement
that didn't target the refr
Hello Joel,
This means, as a user, I might not be aware of the vector restriction when
> adding the foreign keys
> for my existing schema, and think everything is fine, and not realize
> there is a problem until
> new data arrives.
>
Please find v16 with the error message implemented. You can find
Hello Álvaro,
I disagree -- I think we should get the second patch in, and consider it
> a requisite for the other one.
I just want to make sure I got your last message right. We should work on
adding the <<@ and @>> operators and their GIN logic as a separate patch
then submit the FKARRAY as a
Hello Álvaro,
Well, *I* think it makes sense to do it that way. I said so three years
> ago :-)
> https://postgr.es/m/20180410135917.odjh5coa4cjatz5v@alvherre.pgsql
So this makes a lot of sense, let's do that.
> I wonder if it can usefully get cross-type
> operators, i.e., @>>(bigint[],smallin
Hello Stephen,
> Thanks a lot for your persistence, by the way.
> +100
> Hopefully we'll get this in during this cycle and perhaps then you'll work
> on something else? :D
Thank you for your kind words! Yes, hopefully, we'll get this in this time
around. I would definitely love to work on somethi
Hey Joel,
> Here comes a first review of the anyarray_anyelement_operators-v1.patch.
Great, thanks! I’ll start applying your comments today and release a new
patch.
/Mark
Y_ELEMCONTAINED_OP :
> riinfo->pf_eq_oprs[i], // XXX
>
> Is XXX placeholder for some comment you will fill in later ?
>
> Cheers
>
> On Sat, Mar 20, 2021 at 11:42 AM Mark Rofail
> wrote:
>
>> Hey Andreas and Joel!
>>
>> Thank you so much for your hard work
x @>> index”
thus indirectly using the GIN index.
We can definitely add tests to “ src/test/regress/sql/gin.sql” to test
this. Do you agree?
Also what do you mean by “ ginqueryarrayextract needs to be told about this
too”?
Best Regards,
Mark Rofail
>
> Hey Alvaro,
Well, if it's true that it's translated to the commutator, then I don't
>
think any other code changes are needed.
Great, I will get a patch ready tomorrow. Hopefully we’ll wrap up the GIN
part of the patch soon.
/Mark
so it needs to know the type of anyelement (to know if it needs to
> detoast, etc). But there is as far as I can tell no way to check the
> type of anyelement in this context.
>
>
If there is any way to obtain a copy of the datum I would be more than
happy to integrate the GIN operator to the patch.
Best.
Mark Rofail
go down, it doesn't appear
> that the tests were run more than once for each case therefore the
> numbers are pretty noisy
>
Any ideas how to perform more exhaustive tests ?
On 3/26/18 4:50 PM, Mark Rofail wrote:
> > On Wed, Jan 31, 2018 at 1:52 AM, Andre
On Tue, Apr 10, 2018 at 3:59 PM, Alvaro Herrera
wrote:
>
> documentation to it and a few extensive tests to ensure it works well);
I think the existing regression tests verify that the patch works as
expectations, correct?
We need more *exhaustive* tests to test performance, not functionality.
On Tue, 10 Apr 2018 at 4:17 pm, Alvaro Herrera
wrote:
> Mark Rofail wrote:
> I meant for the GIN operator. (Remember, these are two patches, and each
> of them needs its own tests.)
Yes, you are right. I have been dealing with the code as a single patch
that I almost forgot.
Tru
" rather than having unnest() in the target
> list. This way you would not need to rename all columns and the code paths
> for the array case could look more like the code path for the normal case.
>
I have repeatedly tried to generate the suggested query using C code and I
failed. I would like some help with it
Best Regards,
Mark Rofail
.y = a2.v WHERE [...]
>
> rather than:
>
> SELECT fk.k1, fk.ak2 FROM (SELECT x k1, pg_catalog.unnest(ys) k2, ys ak2
> FROM ONLY t2) fk LEFT OUTER JOIN ONLY t1 pk ON pk.x = fk.k1 AND pk.y =
> fk.k2 WHERE [...]
>
Andreas has kindly written the SQL query for us. My problem is generatin
sure they are the same type. Can't
we get the type from the anyarray ? the type is already stored in `
arr_type`.
Best Regards,
Mark Rofail
g that
won't affect the core mechanics of the patch.
So yes, I move towards delaying the introduction of @>> to the patch.
A new patch will be ready by tomorrow.
Besr Regards,
Mark Rofail
>
>
Dear Alvaro,
We just need to rewrite the scope of the patch so I work on the next
generation. I do not know what was "out of scope" in the current version
/Mark
On Tue, 14 Sep 2021, 8:55 pm Alvaro Herrera,
wrote:
> On 2021-Sep-14, Daniel Gustafsson wrote:
>
> > Given the above, and that nothin
I am still having problems rebasing this patch. I can not figure it out on
my own.
On Sun, 27 May 2018 at 5:31 pm, Mark Rofail wrote:
> issue 1: `pg_constraint.c:564`
> I need to check that `conppeqop` is not null and copy it but I don't know
> how to check its type since its a c
il.com
How would we change this so it would be more exhaustive and accurate?
Regards,
Mark Rofail
32 matches
Mail list logo
