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
>
> 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
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
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
>
>
> 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
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
Hey Joel,
I will now proceed with the review of fk_arrays_elem_v2 as well.
>
Great work!!
/Mark
>
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,
+ 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,
> 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
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
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 Á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 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
>
>
> 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
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
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
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,
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
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
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
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 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
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
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.
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
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
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
>
>
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
.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
" 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
32 matches
Mail list logo
