Re: GSoC 2017: Foreign Key Arrays

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Mark Rofail <markm(dot)rofail(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: GSoC 2017: Foreign Key Arrays
Date: 2017-07-14 22:40:56
Message-ID: 20170714224056.hajo5mzjuiryt3bb@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Rofail wrote:
> On Wed, Jul 12, 2017 at 2:30 PM, Mark Rofail <markm(dot)rofail(at)gmail(dot)com> wrote:
>
> > On Wed, Jul 12, 2017 at 12:53 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com
> > > wrote:
> >>
> >> We have one opclass for each type combination -- int4 to int2, int4 to
> >> int4, int4 to int8, etc. You just need to add the new strategy to all
> >> the opclasses.
> >>
> >
> > Can you clarify this solution ? I think another solution would be external
> > casting
> >
> If external casting is to be used. If for example the two types in
> question are smallint and integer. Would a function get_common_type(Oid
> leftopr, Oid rightopr) be useful ?, that given the two types return the
> "common" type between the two in this case integer.

Do you mean adding cast decorators to the query constructed by
ri_triggers.c? That looks like an inferior solution. What problem do
you see with adding more rows to the opclass?

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-07-15 00:06:16 Re: [WIP] Zipfian distribution in pgbench
Previous Message Peter Geoghegan 2017-07-14 22:20:39 The case for removing replacement selection sort