Hi Jörg! >At this point I think ArrayField should always use ARRAY constructor to benefit from the additional sanity checks. But as noted earlier, ARRAY also exposes this weird behavior:
Definitely, FYI Daniele Varrazzo from psycopg2 said https://github.com/psycopg/psycopg2/issues/1507 that >ARRAY[] is an always entertaining booby trap. and that they plan not to use any ARRAY anymore in psycopg3. Now, to fix https://code.djangoproject.com/ticket/34080 I'll try to modify https://github.com/django/django/blob/84206607d6bfd61e7f7a88b51163ffd4153e3b5a/django/contrib/postgres/fields/array.py#L238-L252 as so that the generated template is > "ARRAY[%s::integer[]], " instead of >"ARRAY[%s]:integer[][]" when we have NULL arrays. Still, I'm not sure this behavior is what the django project would like to follow. Your input on this proposal would be very welcome, whether here or in the track ticket. In any case, I'll put all related info at https://code.djangoproject.com/ticket/34080 Thanks again! Le mar. 11 oct. 2022 à 11:33, Jörg Breitbart <j.breitb...@netzkolchose.de> a écrit : > @Ion > > Well I am not deep enough into django's ArrayField for postgres to tell, > which one is the desired output or right behavioral pattern. For my COPY > FROM rewrite I simply tested several edge cases and tried to get as > close as possible to ArrayField. > > From postgres side of things the following is given (trying to recap my > old findings): > - arrays only respect NOT NULL at top level (whole array) > - for array entries there seems to be no way to forbid NULL > - ARRAY constructor is not fully eqivalent to inline '{}' construction > (thats not mentioned in postgres docs!) > > When playing around with inline {} construction vs. ARRAY constructor it > kinda seems, that only ARRAY does certain sanity checks: > - multi dimension balance check > - empty reduction to {} > > At this point I think ArrayField should always use ARRAY constructor to > benefit from the additional sanity checks. But as noted earlier, ARRAY > also exposes this weird behavior: > > postgres=# select ARRAY[null,null]::int[]; --> {NULL,NULL} > postgres=# select ARRAY[null,ARRAY[]]::int[]; --> {} > postgres=# select ARRAY[ARRAY[1,2],ARRAY[3,4]]::int[]; --> {{1,2},{3,4}} > > > which prolly can only be circumvented by some consistency checks in python. > > > Now to the question, whats the right value in DB for > `nested_field=[[None, None]]`: > > Imho if the None here represents a non-array type, things are clear - it > should get constructed just like that: > > postgres=# select ARRAY[ARRAY[null, null]]; --> {{NULL,NULL}} > > If None represents an array-type itself (nested ArrayField), things are > not so clear anymore, as we have again the issue, whether to treat > things in the datatype itself (empty container) vs. sql-null: > > as empty data container: > select ARRAY[ARRAY[ARRAY[], ARRAY[]]]::int[]; --> {} > > as sql-null: > select ARRAY[ARRAY[null, null]]; --> {{NULL,NULL}} > > From pure interface idea this could both be handled by > `null=True|False` argument on the nested ArrayField. But note, that the > ugly reduction on postgres side to {} for empty containers (thus > null=False) creates tons of implementation edge cases during querying, > as all dimension info is lost. So it might be better to always treat > nested ArrayFields as sql-null to preserve some of that info. > > Not sure if any of that helps you, also changing ArrayField behavior too > much might not be wanted at all. > > Overall arrays and even more nested arrays (multidimensional) in > postgres feel somehow like a bad hack with their non-stable dimension, > which imho results from the fact, that postgres does not store that info > during column construction (int[] == int[]...[]). Bummer. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/4OvbN0EUUsM/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/a045a12e-6370-b792-9b96-35fd21566be2%40netzkolchose.de > . > -- [image: img] <https://signitic.app/linkc/L3B5SXlwV0U-L3A4PQ> *Ion Alberdi* [image: img] <https://signitic.app/linkc/L3B5SXlwV0U-L1pzPQ> [image: img] <https://signitic.app/linkc/L3B5SXlwV0U-L3A4PQ> [image: img] <https://signitic.app/linkc/L3B5SXlwV0U-L1pRPQ> [image: img] <https://signitic.app/linkc/L3B5SXlwV0U-L1pnPQ> [image: img] <https://signitic.app/linkc/L3B5SXlwV0U-L1prPQ> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANbgw4D%2Bu63WJ%3Du1Wi18ApPwRo6mZgZVKH-6qZFzDWMdtHto5Q%40mail.gmail.com.
