Skip site navigation (1) Skip section navigation (2)

Re: proposal: Preference SQL

From: Decibel! <decibel(at)decibel(dot)org>
To: Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl>
Cc: Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: Preference SQL
Date: 2008-06-03 21:57:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On May 29, 2008, at 6:08 PM, Jan Urbański wrote:
> Now about the idea itself:
> publications/all_db_tech-reports/tr-2001-7_kie_koe/ 
> tr-2001-7_kie_koe.pdf
> That's one of the basic papers about Preference SQL, explaining  
> what it's all about. For those, who don't feel like reading through  
> it just because I said it's interesting, here's some more info  
> (warning, it's a bit formal):
> Preference SQL is an extension to regular SQL, that allows  
> expressing preferences in SQL queries. Preferences are like "soft"  
> WHERE clauses. A preference doesn't need to be satisfied by a tuple  
> for it to appear in the result set, but it's "preferred" it is.  
> More strictly, a set of preference clauses in a SQL query defines a  
> partial order on the result set as it would appear without any  
> preference clauses and then returns the maximal elements.
> The partial order imposed by the set of preferences P[1], P 
> [2], ..., P[n] is such that tuple T1 > T2  iff  T1 all preferences  
> T2 satisfies and there is a preference satisfied by T1 and not  
> satisfied by T2 (or there is a preference satisfied by T1 that is  
> "better" satisfied by T2 and all others are "equaly" satisfied). As  
> can be seen, there could be an order defined on the degree of  
> satisfyiness of a preference, and the exact semantics are not all  
> that well defined for all concievable cases. Defining a complete  
> semantics will be a part of my thesis.

This seems like a subset of ... or  
do I misunderstand?
Decibel!, aka Jim C. Nasby, Database Architect  decibel(at)decibel(dot)org
Give your computer some brain candy! Team #1828

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-06-03 22:04:13
Subject: Re: Change lock requirements for adding a trigger
Previous:From: Decibel!Date: 2008-06-03 21:48:08
Subject: Re: Change lock requirements for adding a trigger

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group