Hi Stefan,
On 2021-Oct-03, Stefan Keller wrote:
> Just for my understanding - and perhaps as input for the documentation of
> this:
> Are Foreign Key Arrays a means to implement "Generic Foreign Keys" as
> in Oracle [1] and Django [2], and of "Polymorphic Associations" as
> they call this in Rub
Dear all
Just for my understanding - and perhaps as input for the documentation of this:
Are Foreign Key Arrays a means to implement "Generic Foreign Keys" as
in Oracle [1] and Django [2], and of "Polymorphic Associations" as
they call this in Ruby on Rails?
Yours, Stefan
[1] Steven Feuerstein a
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
> On 14 Sep 2021, at 20:54, Alvaro Herrera wrote:
>
> On 2021-Sep-14, Daniel Gustafsson wrote:
>
>> Given the above, and that nothing has happened on this thread since this
>> note,
>> I think we should mark this Returned with Feedback and await a new
>> submission.
>> Does that seem reasonabl
On 2021-Sep-14, Daniel Gustafsson wrote:
> Given the above, and that nothing has happened on this thread since this note,
> I think we should mark this Returned with Feedback and await a new submission.
> Does that seem reasonable Alvaro?
It seems reasonable to me.
--
Álvaro Herrera
> On 14 Jul 2021, at 18:07, Alvaro Herrera wrote:
>
> On 2021-Jul-14, vignesh C wrote:
>
>> The patch does not apply on Head anymore, could you rebase and post a
>> patch. I'm changing the status to "Waiting for Author".
>
> BTW I gave a look at this patch in the March commitfest and concluded
On 2021-Jul-14, vignesh C wrote:
> The patch does not apply on Head anymore, could you rebase and post a
> patch. I'm changing the status to "Waiting for Author".
BTW I gave a look at this patch in the March commitfest and concluded it
still requires some major surgery that I didn't have time for
On Tue, Mar 30, 2021 at 2:14 AM Mark Rofail wrote:
>
> Hey Alvaro
>
>> Yes, we should do that.
>
> I have attached v12 with more tests in “ src/test/regress/sql/gin.sql”
>
> Changelog:
> - v12 (compatible with current master 2021/03/29, commit
> 6d7a6feac48b1970c4cd127ee65d4c487acbb5e9)
> * a
>
> 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
On 2021-Mar-27, Mark Rofail wrote:
> Hello Alvaro,
>
> Looking at 0001+0003, I see it claims GIN support for <<@ and @>>, but
> > actually only the former is implemented fully; the latter is missing a
> > strategy number in ginarrayproc.c and pg_amop.dat, and also
> > src/test/regress/sql/gin.sql
Hello Alvaro,
Looking at 0001+0003, I see it claims GIN support for <<@ and @>>, but
> actually only the former is implemented fully; the latter is missing a
> strategy number in ginarrayproc.c and pg_amop.dat, and also
> src/test/regress/sql/gin.sql does not test it. I suspect
> ginqueryarrayext
Looking at 0001+0003, I see it claims GIN support for <<@ and @>>, but
actually only the former is implemented fully; the latter is missing a
strategy number in ginarrayproc.c and pg_amop.dat, and also
src/test/regress/sql/gin.sql does not test it. I suspect
ginqueryarrayextract needs to be told a
Hi Zhihing,
I think @Andreas ment to mark it as a todo to cleanup later.
On Sun, 21 Mar 2021 at 4:49 AM Zhihong Yu wrote:
> Hi,
> In v11-0004-fk_arrays_elems_edits.patch :
>
> + riinfo->fk_reftypes[i] ==
> FKCONSTR_REF_EACH_ELEMENT ? OID_ARRAY_ELEMCONTAINED_OP :
> riinf
Hi,
In v11-0004-fk_arrays_elems_edits.patch :
+ riinfo->fk_reftypes[i] ==
FKCONSTR_REF_EACH_ELEMENT ? OID_ARRAY_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 Ro
>
>
> 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
On Fri, Mar 12, 2021 at 11:32:27PM +0200, Mark Rofail wrote:
> I have retested the patch on a windows build and it passes the regression
> tests thanks to Justin's recommendations. Hopefully, it will pass CI too.
>
> Changelog:
> - v7 (compatible with current master 2021-3-12,
> commit 02b5940dbe
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
On Wed, Mar 03, 2021 at 11:31:49PM +0200, Mark Rofail wrote:
> This is just a rebase patch since the patch is no longer applicable to the
> current master.
It doesn't just rebase: it also removes the test which was failing on windows
CI:
--- Try using the indexable operator
-SELECT * FROM FKTABLE
On Tue, Feb 16, 2021 at 12:07:10PM +0200, Mark Rofail wrote:
...
There's some errors in the latest patch:
http://cfbot.cputube.org/mark-rofail.html
gram.y:16933:20: error: invalid operands to binary expression ('List' (aka
'struct List') and 'void *')
Assert(**reftypes != NULL);
Did yo
Hey Joel,
I will now proceed with the review of fk_arrays_elem_v2 as well.
>
Great work!!
/Mark
>
Hi all,
On Tue, Feb 16, 2021, at 11:07, Mark Rofail wrote:
>Changelog:
>- anyarray_anyelement_operators-v4 (compatible with current master 2021-02-16,
>>commit f672df5fdd22dac14c98d0a0bf5bbaa6ab17f8a5)
>* revert anycompatiblenonarray in docs to anyelement
Good.
I've marked anyarray_anyeleme
On Mon, Feb 15, 2021, at 20:34, Mark Rofail wrote:
>Dear All,
>
>I know that avoiding trivial coercion problems is convenient but at the end of
>the day,
>it's the DB Architect's job to use the proper tables to be able to use FK
>Arrays.
>For instance, if we have two tables, TABLE A (atest1 int2
Hi all,
I've reviewed Mark's anyarray_anyelement_operators-v2.patch
and the only remaining issue I've identified is the opr_sanity problem.
Mark seems to be in need of some input here from more experienced hackers, see
below.
Hopefully someone can guide him in the right direction.
/Joel
On Sa
On Sat, Feb 13, 2021, at 12:35, Joel Jacobson wrote:
>psql:type-test.sql:165: WARNING:
>SQL queries produced different results:
>SELECT '285970053'::pg_catalog."numeric" =
>ANY(ARRAY['285970053']::pg_catalog.float4[])
>false
>SELECT '285970053'::pg_catalog."numeric" <<@
>ARRAY['285970053']::pg_ca
On Fri, Feb 12, 2021, at 20:56, Mark Rofail wrote:
>Attachments:
>anyarray_anyelement_operators-v2.patch
I've created a quite sophisticated test in PL/pgSQL,
that takes advantage of all the test data produced
by the official PostgreSQL regression test suite.
It goes through all tables and columns
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
Hi again Mark,
On Fri, Feb 12, 2021, at 20:56, Mark Rofail wrote:
>Attachments:
>anyarray_anyelement_operators-v2.patch
One regression test fails on my machine:
make installcheck
test opr_sanity ... FAILED 3994 ms
1 of 202 tests failed.
Hi Mark,
>On Fri, Feb 12, 2021, at 20:56, Mark Rofail wrote:
>Attachments:
>anyarray_anyelement_operators-v2.patch
Some more code review comments:
Comparing the v1 and v2 patch, I noticed this change in array_contains_elem():
+ oprresult = DatumGetBool(FunctionCallInvoke(locfcinfo));
-+ if (oprr
Hi Mark,
On Fri, Feb 12, 2021, at 20:56, Mark Rofail wrote:
>Indeed you are right, to support the correct behaviour we have to use
>@>>(anycompatiblearray, anycompatiblenonarry) and >this throws a sanity error
>in opr_santiy since the left operand doesn't equal the gin opclass which is
>anyarra
>On Thu, Feb 11, 2021, at 16:50, Mark Rofail wrote:
>> 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.
Here comes some more feedback:
I was surprised to see <<@ and @>> don't complain when tr
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
Hi Mark,
On Mon, Feb 8, 2021, at 09:40, Mark Rofail wrote:
> anyarray_anyelement_operators-v1.patch
Here comes a first review of the anyarray_anyelement_operators-v1.patch.
doc/src/sgml/func.sgml
+Does the array contain specified element ?
* Maybe remove the extra blank space before que
Hi Mark,
On Mon, Feb 8, 2021, at 09:40, Mark Rofail wrote:
>Attachments:
>fk_arrays_elem_v1.patch
>anyarray_anyelement_operators-v1.patch
Nice work!
I have successfully tested both patches against
e7f42914854926c2afbb89b9cd0e381fd90766be
by cloning all pg_catalog tables, and adding foreign keys
[Found it :-)]
On 2021-Feb-05, Mark Rofail wrote:
> We will focus on getting the operator patch through first. Should I create
> a separate commitfest ticket? or the current one suffices?
> https://commitfest.postgresql.org/32/2966/
I think the current one is fine. In fact I would encourage you
On 2021-Feb-07, Mark Rofail wrote:
> Changelog (operator patch):
> > - v1 (compatible with current master 2021-02-05,
> > commit c72af5c202067a9ecb0ff8df7370fb1ea8f4)
> > * add tests and documentation to array operators and gin index
> >
> Since we agreed to separate @>> and <<@ operators
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
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2021-Feb-05, Mark Rofail wrote:
> > 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
> >
Hello Mark
On 2021-Feb-05, Mark Rofail wrote:
> 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 se
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
On 2021-Feb-05, Mark Rofail wrote:
> I believe we should start merging these two patches as one, due to the Elem
> addon's benefits. such as adding Composite Type support.
I disagree -- I think we should get the second patch in, and consider it
a requisite for the other one. Let's iron it out fu
Hi,
For Array-containselem-gin-v4.patch , one small comment:
+ * array_contains_elem : checks an array for a spefific element
typo: specific
Cheers
On Thu, Feb 4, 2021 at 4:03 PM Mark Rofail wrote:
> Hello Joel,
>
> No error, even though bigint[] isn't compatible with smallint.
>>
> I added a
On Tue, Feb 2, 2021, at 13:51, Mark Rofail wrote:
>Array-ELEMENT-foreign-key-v17.patch
When working on my pit tool, I found another implicit type casts problem.
First an example to show a desired error message:
CREATE TABLE a (
a_id smallint,
PRIMARY KEY (a_id)
);
CREATE TABLE b (
b_id bigint,
Hi Mark,
On Thu, Jan 28, 2021, at 22:41, Mark Rofail wrote:
>Please find v16 with the error message implemented. You can find it in the
>previous message.
Thanks! It's working fine:
ERROR: (int2vector) is not an array type, cannot be used as a referencing
column
I've pushed a first working dr
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
Hi Mark,
On Wed, Jan 27, 2021, at 22:36, Mark Rofail wrote:
> Vectors as refrencing columns are not supported and out of scope of this
> patch. Try to use arrays.
OK, not a biggie, but I think the user at least should get an error message
immediately when trying to add the foreign key on an inco
Hi, Mark:
+ if (ARR_NDIM(arr) != 1 ||
+ ARR_HASNULL(arr) ||
+ ARR_ELEMTYPE(arr) != CHAROID)
+ elog(ERROR, "confreftype is not a 1-D char array");
I think the ARR_HASNULL(arr) condition is not reflected in the error
message.
+* Array foreign keys support on
>
>
> 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
Hi Mark,
On Wed, Jan 27, 2021, at 20:34, Mark Rofail wrote:
>Here it is.
>Array-ELEMENT-foreign-key-v15.patch
Thanks.
I've tested it and notice there still seems to be a problem with int2vector?
Reading your previous comment a few messages ago,
it sounds like this was fixed, but perhaps not?
Hi Mark,
On Wed, Jan 27, 2021, at 10:58, Mark Rofail wrote:
>Kindly find the updated patch (v15) below
I think you forgot to attach the patch.
/Joel
Hi Joel,
As always, great catch!
Kindly find the updated patch (v15) below
Changelog:
- v15 (compatible with current master 2021-01-27, commit
e42b3c3bd6a9c6233ac4c8a2e9b040367ba2f97c)
* remove "EACH ELEMENT OF" from violation messages
* accommodate tests accordingly
Keep up the good wor
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:
UPDATE catalog_clone.pg_extension SET extconfig = ARRAY[12345] WHERE oid = 10;
ERROR: insert or update on table "pg_extension" violates
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
Hi Mark,
On Mon, Jan 25, 2021, at 09:14, Joel Jacobson wrote:
> I'll continue testing over the next couple of days and report if I find any
> more oddities.
I've continued testing by trying to make full use of this feature in the
catalog-diff-tool I'm working on.
Today I became aware of a SQL
On Sun, Jan 24, 2021, at 21:46, Mark Rofail wrote:
>Thank you for this find, please find the fix below
Many thanks for fixing. I can confirm it now works like expected for the
reported case:
CREATE SCHEMA catalog_clone;
CREATE TABLE catalog_clone.pg_proc AS SELECT * FROM pg_catalog.pg_proc;
CREA
On 2021-Jan-24, Mark Rofail wrote:
> I do not think that postgres contains vector operators, correct me if I am
> wrong. I feel that supporting vectors is our of the scope of this patch, if
> you have an idea how to support it please let me know.
I do not think that this patch needs to support oi
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
Hi again,
I found a similar problem with int2vector columns:
CREATE TABLE catalog_clone.pg_index AS SELECT * FROM pg_catalog.pg_index;
CREATE TABLE catalog_clone.pg_attribute AS SELECT attrelid,attnum FROM
pg_catalog.pg_attribute;
ALTER TABLE catalog_clone.pg_attribute ADD UNIQUE (attrelid, attn
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
On Sun, Jan 24, 2021, at 11:21, Mark Rofail wrote:
>This seems to be a type casting problem indeed. The coercion part of the patch
>found in "ruleutils.c:11438-11491" is the culprit, is there a cleaner way to
>achieve this?
>I am aware of the problem and will try to fix it, but I assume this is b
Hi Mark and others,
On Sun, Jan 24, 2021, at 09:22, Mark Rofail wrote:
> Changelog:
> - v13 (compatible with current master 2021-01-24, commit
> 7e57255f6189380d545e1df6a6b38827b213e3da)
...
> I encourage everyone to take review this patch. After considerable reviews
> and performance testing, i
Hi, Mark:
+ CREATE TABLE races (
Maybe 'racings' is a better name for the table (signifying the activities).
+ if (ARR_NDIM(arr) != 1 ||
+ ARR_DIMS(arr)[0] != numkeys ||
+ ARR_HASNULL(arr) ||
+ ARR_ELEMTYPE(arr) != CHAROID)
+ elog(ERROR, "confref
Greetings,
I am trying to revive this patch, Foreign Key Arrays. The original proposal
from my GSoC 2017 days can be found here:
https://www.postgresql.org/message-id/CAJvoCut7zELHnBSC8HrM6p-R6q-NiBN1STKhqnK5fPE-9%3DGq3g%40mail.gmail.com
Disclaimer, I am not the original author of this patch, I p
On Sat, Aug 11, 2018 at 05:20:57AM +0200, Mark Rofail wrote:
> I am still having problems rebasing this patch. I can not figure it out on
> my own.
Okay, it's been a couple of months since this last email, and nothing
has happened, so I am marking it as returned with feedback.
--
Michael
signatu
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 char*
>
> issue 2
I was wondering if anyone knows the proper way to write a benchmarking test
for the @>> operator. I used the below script in my previous attempt
https://gist.github.com/markrofail/174ed370a2f2ac24800fde2fc27e2d38
The script does the following steps:
1. Generate Table A with 5 rows
2. Generate Tabl
Mark Rofail wrote:
> > In particular: it seemed to me that you decided to throw away the idea
> > of the new GIN operator without sufficient evidence that it was
> > unnecessary.
>
> I have to admit to that. But in my defence @> is also GIN indexable so the
> only difference in performance betwee
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.
True. So my impres
Mark Rofail wrote:
> 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?
I meant for the GIN operator. (Remember,
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.
Mark Rofail wrote:
> Hello David,
>
> On Tue, Apr 10, 2018 at 3:47 PM, David Steele wrote:
>
> > You should produce a new version by then that addresses Alvaro's
> > concerns and I imagine that will require quite a bit of discussion and
> > work.
>
> I'll get working.
> I'll produce a patch wit
Hello David,
On Tue, Apr 10, 2018 at 3:47 PM, David Steele wrote:
> You should produce a new version by then that addresses Alvaro's
> concerns and I imagine that will require quite a bit of discussion and
> work.
I'll get working.
I'll produce a patch with two alternate versions, one with and
Hi Mark,
On 3/26/18 4:50 PM, Mark Rofail wrote:
> On 3/7/18 5:43 AM, Alvaro Herrera wrote:
>
> I searched for the new GIN operator so that I
> could brush it up for commit ahead of the rest -- only to find out that
> it was eviscerated from the patch between v5 and v5.1.
>
> The late
On 3/7/18 5:43 AM, Alvaro Herrera wrote:
I searched for the new GIN operator so that I
> could brush it up for commit ahead of the rest -- only to find out that
> it was eviscerated from the patch between v5 and v5.1.
>
> The latest version of the patch which contained the new GIN operator is
vers
On 3/7/18 5:43 AM, Alvaro Herrera wrote:
>
> At this point I'm not sure what to do with this patch. It needs a lot
> of further work, for which I don't have time now, and given the pressure
> we're under I think we should punt it to the next dev cycle.
>
> Here's a rebased pgindented version. I
Andreas Karlsson wrote:
> On 02/06/2018 11:15 AM, Mark Rofail wrote:
> > A new patch including all the fixes is ready.
> >
> > Can you give the docs another look. I re-wrapped, re-indented and
> > changed all `Foreign Key Arrays` to `Array Element Foreign Keys` for
> > consistency.
>
> Looks goo
On 02/06/2018 11:15 AM, Mark Rofail wrote:
A new patch including all the fixes is ready.
Can you give the docs another look. I re-wrapped, re-indented and
changed all `Foreign Key Arrays` to `Array Element Foreign Keys` for
consistency.
Looks good to me so set it to ready for committer. I s
The patch looks good to me now other than some smaller issues, mostly in
the documentation. If you fix these I will set it as ready for
committer, and let a committer chime in on the casting logic which we
both find a bit ugly.
== Comments
The only a bit bigger issue I see is the error messag
On Sat, 3 Feb 2018 at 5:14 pm, Andreas Karlsson wrote:
> If I am right my recommendation for getting this patch in is to
> initially skip the new operators and go back to the version of the patch
> which uses @>.
We really need an initial patch to get accepted and postpone anything that
won't a
On 02/01/2018 04:17 PM, Mark Rofail wrote:
since its a polymorphic function it only passes if the `anyarray` is the
same type of the `anyelement` so we are sure they are the same type.
Can't we get the type from the anyarray ? the type is already stored in
` arr_type`.
In theory, yes, but I s
On Wed, Jan 31, 2018 at 1:52 AM, Andreas Karlsson wrote:
> I looked some at your anyarray @>> anyelement code and sadly it does not
> look like the index code could work. The issue I see is that
> ginqueryarrayextract() needs to make a copy of the search key but to do so
> it needs to know the ty
On 01/21/2018 10:36 PM, Mark Rofail wrote:
== The @>> operator
A previous version of your patch added the "anyelement <<@ anyarray"
operator to avoid having to build arrays, but that part was reverted
due to a bug.
I am not expert on the gin code, but as far as I can tell it
On Mon, Nov 13, 2017 at 2:41 AM, Andreas Karlsson wrote:
> I think the code would look cleaner if you generate the following query:
>
> SELECT fk.x, fk.ys FROM ONLY t2 fk CROSS JOIN LATERAL
> pg_catalog.unnest(ys) a2 (v) LEFT OUTER JOIN ONLY t1 pk ON pk.x = fk.x AND
> pk.y = a2.v WHERE [...]
>
>
Mark Rofail wrote:
> > 1) MATCH FULL does not seem to care about NULLS in arrays. In the example
> > below I expected both inserts into the referring table to fail.
> >
> > CREATE TABLE t (x int, y int, PRIMARY KEY (x, y));
> > CREATE TABLE fk (x int, ys int[], FOREIGN KEY (x, EACH ELEMENT OF ys)
According to the last review, there are still two main issues with the
patch.
On Mon, Oct 30, 2017 at 3:24 AM, Andreas Karlsson wrote:
> 1) MATCH FULL does not seem to care about NULLS in arrays. In the example
> below I expected both inserts into the referring table to fail.
>
> CREATE TABLE t
Here's a rebased version of this patch. I have done nothing other than
fix the conflicts and verify that it passes existing regression tests.
I intend to go over the reviews sometime later and hopefully get it all
fixed for inclusion in pg11.
--
Álvaro Herrerahttps://www.2ndQuadr
On Mon, Nov 27, 2017 at 10:47 AM, Andreas Karlsson wrote:
> Cool, feel free to ask if you need some assistance. I want this patch.
The last patch submitted did not get a review, and it does not apply
as well. So I am moving it to next CF with waiting on author as
status. Please rebase the patch.
On 11/13/2017 12:32 PM, Mark Rofail wrote:
== The @>> operator
I would argue that allocating an array of datums and building an
array would have the same complexity
I am not sure what you mean here. Just because something has the
same complexity does not mean the
89 matches
Mail list logo
