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

Re: Planner question - "bit" data types

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Karl Denninger <karl(at)denninger(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera<alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure<mmoncure(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>,"pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Planner question - "bit" data types
Date: 2010-02-23 23:51:43
Message-ID: 206E5F2A-9E9B-4D46-A260-42FBAFD2273B@richrelevance.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Sep 7, 2009, at 7:05 PM, Karl Denninger wrote:

The individual boolean fields don't kill me and in terms of some of the application issues they're actually rather easy to code for.

The problem with re-coding for them is extensibility (by those who install and administer the package); a mask leaves open lots of extra bits for "site-specific" use, where hard-coding booleans does not, and since the executable is a binary it instantly becomes a huge problem for everyone but me.

It does appear, however, that a bitfield doesn't evaluate any differently than does an integer used with a mask, so there you have it..... it is what it is, and if I want this sort of selectivity in the search I have no choice.

Perhaps, use a view to encapsulate the extensible bit fields?  Then custom installations just modify the view?  I haven't thought through that too far, but it might work.


-- Karl
<karl.vcf>
--
Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org<mailto:pgsql-performance(at)postgresql(dot)org>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

In response to

pgsql-performance by date

Next:From: Dave CrookeDate: 2010-02-24 08:32:40
Subject: Re: SSD + RAID
Previous:From: Dave CrookeDate: 2010-02-23 23:37:04
Subject: Thx and additional Q's .....

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