Re: Overloaded && operator from intarray module prevents index usage.

From: Ron <ronljohnsonjr(at)gmail(dot)com>
To: PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Overloaded && operator from intarray module prevents index usage.
Date: 2019-03-01 02:19:46
Message-ID: 16afa0dd-5520-34bd-0ea5-bedc8e2096cb@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2/28/19 7:53 PM, Michael Lewis wrote:
>
>
> On Thu, Feb 28, 2019 at 4:57 PM Ron <ronljohnsonjr(at)gmail(dot)com
> <mailto:ronljohnsonjr(at)gmail(dot)com>> wrote:
>
> On 2/28/19 4:53 PM, Michael Lewis wrote:
> [snip]
>> Would a sixth option be to re-create the column as array type
>
> Codd is spinning in his grave...
>
>
> I'd hope he would be fine with people asking questions to learn. I'm open
> to studying any suggested resources. I also love to learn from those with
> experience who are further down this path, just as I love to share my
> experience with people who don't from a WHERE from a HAVING. If there is
> anything specific you can point me to, please do chime in with something
> constructive.

Michael,

E. F. Codd developed the relational model, and Normal Forms to structure the
attributes (columns), tuples (rows) and relations (tables).  They work to
prevent insert, update and delete anomalies.

Quoting him in /The Relational Model for Database Management Version 2/ from
1990: "values in the domains on which each relation is defined are required
to be atomic with respect to the DBMS."

Arrays are -- by definition -- not atomic, and so they fundamentally break
the model that relational databases are founded upon.  If you want to be a
good database designer, don't use arrays.

(Darwen and Date deconstruct "atomic value" into meaninglessness by claiming
that, for example, strings are arrays of characters and thus arrays are ok. 
I think that's bollocks.)

--
Angular momentum makes the world go 'round.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron 2019-03-01 02:22:53 Re: validation of hot standby
Previous Message Julie Nishimura 2019-03-01 02:00:41 validation of hot standby