Обсуждение: Operation on bit strings with different length

Поиск
Список
Период
Сортировка

Operation on bit strings with different length

От
S P Arif Sahari Wibowo
Дата:
Hi!

Do you know how to operate (AND, OR, etc.) on bit strings with
dynamically different length? It is dynamic, means the length won't be
determined until run time.
Is there any function to extend the length of a bit string to a certain
length?

Thank you!

--
                                   S P Arif Sahari Wibowo
  _____  _____  _____  _____
 /____  /____/ /____/ /____          arifsaha@yahoo.com
_____/ /      /    / _____/       http://www.arifsaha.com/


Re: Operation on bit strings with different length

От
"Josh Berkus"
Дата:
Arif,

For future notice, the NOVICE list is the appropriate place for this
type of question.

> Do you know how to operate (AND, OR, etc.) on bit strings with
> dynamically different length? It is dynamic, means the length won't
> be
> determined until run time.
> Is there any function to extend the length of a bit string to a
> certain
> length?

PostgreSQL is currently (as far as I know) lacking a good set of bitwise
data types and operators.  If you really need to use them, I suggest
that you construct them -- Postgres allows you to build your own data
types, and operators for those data types.  It's a somewhat
labor-intensive process.

Most of us don't have much use for bitwise operations in the database,
because the essential intent of a bitwise number is to store several
different pieces of data in the same number.  This goes against
relational principles, which say that each field should be "atomic";
that is, containing one and only one piece of information.

If, however, you are interacting with the MS API, I can see why you
would need bitwise logic.  So my suggestions are:

1. Create your own data types and operators per paragraph 1;
2. Just store the integer in Postgres, and do your bitwise logic in your
interface/middleware language.

-Josh Berkus

-Josh Berkus


______AGLIO DATABASE SOLUTIONS___________________________
                                       Josh Berkus
  Complete information technology      josh@agliodbs.com
   and data management solutions       (415) 565-7293
  for law firms, small businesses        fax 621-2533
    and non-profit organizations.      San Francisco

Stupid question on INDEXES

От
"Giorgio Ponza"
Дата:
I'd like to know if i think in the right way. With
CREATE TABLE Test1 (
my_id int,
descr text,
primary key (my_id))
Postgres automatically creates an index named test1_pkey.
If i use
CREATE TABLE Test1 (
my_id int,
descr text)
without specifying a pkey, i can write
create unique index i_test1_pkey on (my_id).
The only difference is that in the 2nd case i can use the name i want, or
the usage is different?

Many thanks

Giorgio



Re: Stupid question on INDEXES

От
Tom Lane
Дата:
"Giorgio Ponza" <giorgio@opla.it> writes:
> I'd like to know if i think in the right way. With
> CREATE TABLE Test1 (
> my_id int,
> descr text,
> primary key (my_id))
> Postgres automatically creates an index named test1_pkey.
> If i use
> CREATE TABLE Test1 (
> my_id int,
> descr text)
> without specifying a pkey, i can write
> create unique index i_test1_pkey on (my_id).
> The only difference is that in the 2nd case i can use the name i want, or
> the usage is different?

There are two things that are different:

1. PRIMARY KEY implies NOT NULL.  You'd need to declare the column as
NOT NULL in the second CREATE TABLE to have exactly equivalent
constraints.

2. When a PRIMARY KEY is declared, the column(s) become the default
columns for a FOREIGN KEY declaration in another table, so you could
write "REFERENCES Test1" without having to mention my_id as the
referenced column.  Without a PRIMARY KEY, you'll have to mention my_id
explicitly.  But this is only a notational convenience.

            regards, tom lane