Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}

Martijn van Oosterhout <kleptog@svana.org>

From: Martijn van Oosterhout <kleptog@svana.org>
To: Peter Geoghegan <pg@heroku.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, Jeff Janes <jeff.janes@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>, Craig Ringer <craig@2ndquadrant.com>, Anssi Kääriäinen <anssi.kaariainen@thl.fi>, Simon Riggs <simon@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Kevin Grittner <kgrittn@ymail.com>, Andres Freund <andres@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-12-20T10:16:47Z
Lists: pgsql-hackers
On Fri, Dec 19, 2014 at 05:32:43PM -0800, Peter Geoghegan wrote:
> > Most people would list the columns, but if there is a really bizarre
> > constraint, with non-default opclasses, or an exclusion constraint, it's
> > probably been given a name that you could use.
> 
> What I find curious about the opclass thing is: when do you ever have
> an opclass that has a different idea of equality than the default
> opclass for the type? In other words, when is B-Tree strategy number 3
> not actually '=' in practice, for *any* B-Tree opclass? Certainly, it
> doesn't appear to be the case that it isn't so with any shipped
> opclasses - the shipped non-default B-Tree opclasses only serve to
> provide alternative notions of sort order, and never "equals".

Well, in theory you could build a case insensetive index on a text
column. You could argue that the column should have been defined as
citext in the first place, but it might not for various reasons.

Have a nice day,
-- 
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
   -- Arthur Schopenhauer

Commits

  1. Change the way we mark tuples as frozen.

  2. Add documentation for data-modifying statements in WITH clauses.