Обсуждение: Boolean and Bit
Hello All, This is my first post (so be gentle with me)... Is there a searchable archive? I would like suggestions and examples of adding SQL-92 data type BIT compatibility to a PostgreSQL schema. >From the doc's I gather you can "CREATE TYPE bit" with storage int or int4... but I don't know about the input/output for zero and one. Should SQL (ODBC) be able to ask "WHERE bitfield;" or should it ask "WHERE bitfield = 1;" ? Any response gratefully recognized... Keith
Keith, > This is my first post (so be gentle with me)... Well, yea-hah! Fresh meat, boys! Bring out the branding iron and the Wayne Newton B-sides! > I would like suggestions and examples of adding SQL-92 > data type BIT compatibility to a PostgreSQL schema. First let me ask you: Why do you want a Bit type? What purpose does it serve that INT2 and BOOLEAN do not? I'm not being sarcastic -- this is an important question to ask before creating *any* custom type on any RDBMS. -Josh Berkus
Keith, > This is a compatibility issue. While I prefer to use > BOOLEAN, this is SQL3 > and not available on the (unfortunately must use) > MS-SQL/MSDE platform. > > My options are to use a CHAR field and re-write my code > for "T" and "F" or > an int field and re-write my code to use "field=0" and > "field<>0" Given that all the MS-SQL BIT field is, is INT1, using INT2 should not be much of a problem. Go ahead an create a custom type based on INT2 and add constraints to prevent any values outside of the range of 0 and 1. This is where the SQL92 DOMAIN (not, as far as I know, available in PGSQL) construction would be useful in PostgreSQL instead of TYPE (Tom?). The problem with TYPE is that you theoretically need to define a whole set of operators for your TYPE, while DOMAIN is a bit simpler. > I would like to distribute a script (SQL) file to our > users to update > databases to new versions... obstacles include > BOOLEAN/BIT and the > inconsistent use of BLOB/MEMO/[long]varchar(4096). Well, yes. This is beacause BLOBs are NOT part of the SQL standard and IMHO a bad idea relationally; thus their implementation is entirely proprietary to the RDBMS. The solution is not to use BLOBs. > Distributing schema patches is proving troublesome across > multiple > platforms. Yup. Yer in for a world of pain, sonny. Hope you get paid hourly. -Josh
Josh Berkus wrote:
> Well, yes. This is beacause BLOBs are NOT part of the SQL
> standard and IMHO a bad idea relationally; thus their
> implementation is entirely proprietary to the RDBMS. The
> solution is not to use BLOBs.
Ooops. Let me re-state: This is because the *implementation* of BLOBS
is not defined in the SQL standard, and BLOBs are IMHO a bad idea for
relational database design, as they violate Codd's Rules. Thus the
implementation of, anf functions and operators for BLOBs are entirely
proprietary to the RDBMS platform.
The solution to this is not to use BLOBs, but rather to use file system
handles for the location of the binary data on the server. This way,
all you need is DOS-to-UNIX and UNIX-to-DOS translation for the
filesystem handles, something easily accomplished through
string-manipulation functions or stored procedures.
-Josh Berkus
--
______AGLIO DATABASE SOLUTIONS___________________________ Josh Berkus Complete
informationtechnology josh@agliodbs.com and data management solutions (415) 436-9166 for law firms, small
businesses fax 436-0137 and non-profit organizations. pager 338-4078 San
Francisco
Josh Berkus wrote: > > > The solution to this is not to use BLOBs, but rather to use file system > handles for the location of the binary data on the server. This way, > all you need is DOS-to-UNIX and UNIX-to-DOS translation for the > filesystem handles, something easily accomplished through > string-manipulation functions or stored procedures. > > -Josh Berkus Do you have an example for implementing this?