Intellect Board — cистема управления сайтом

И кроме всего прочего, есть различия в типах данных:
мускульному BLOB примерно соответсвтует тип BYTEA,
наиболее близким к TINYINT (однобайтовое целое) является SMALLINT (двухбайтовое целое), но предпочтительне использовать INT (INTEGER),
BOOL и BIT в MySQL не соответствуют таким же в PostgreSQL
Это то, что всмоинилось навскидку, есть и еще различия — нужно в доки заглянуть...

Еще вспомнил — в Постгри есть типы SERIAL и BIGSERIAL - аналог INT (BIGINT) с флагом AUTOINCREMENT

В PostgreSQL мощный и гибкий полнотекстовый поиск с возмоностью подключения словарей, но реализуется в корне отличным то MySQL способом, индексов типа мускульного FULLTEXT, в Постгри не существует. Full-text-поиск обеспечивает модуль contrib/tsearch2, для поиска используются тополнительные поля типа tsvector.
Например, создание таблицы prefix_Post, для полнотекстового поиска добаляется еще одно поле (fulltext_idx) типа tsvector:


  CREATE TABLE prefix_Post (
  p_id SERIAL,
.....
  p_text TEXT NOT NULL,
.....
  p_title VARCHAR(64) NOT NULL,
.....
  fulltext_idx tsvector,
  PRIMARY KEY(p_id)
);
  

  UPDATE prefix_Post SET fulltext_idx = to_tsvector('default',coalesce(p_text,'') ||' '|| coalesce(p_title,''));

  VACUUM FULL ANALYZE prefix_Post;

  CREATE INDEX idx_fulltext_idx ON prefix_Post USING gist(fulltext_idx);

Автозаполнение этого поля можно обеспечить разными способами, на мой взгляд, самый удобный — через триггер:

  CREATE TRIGGER tg_fulltext_prefix_Post
  BEFORE UPDATE OR INSERT ON prefix_Post
  FOR EACH ROW EXECUTE PROCEDURE
    tsearch2(fulltext_idx, p_text, p_title);

Поисковый запрос будет выглядеть примерно так:

  SELECT p_id, p_text FROM prefix_Post
          WHERE fulltext_idx @@  to_tsquery('слово1 & слово2 & слово3 ...');


P.S. Разумеется, модуль tsearch2 к моменту создания таблиц должен быть подключен к базе.

wsx написал:

[q]

SERIAL, BIGSERIAL и их наследники - являются не ТИПАМИ, а АлиАсами к INTEGER, но с небольшим "триггером", который создаёт требуемую секвенцию.

[/q]

С точки зрения администратора БД - совершенно верно, но с точки зрения пользователя БД - это самый обыкновенный, кстати декларированный в описании, тип.


XXXX Pro
Поковырялся с русским поиском... В связи с тем, что не всегда возможно изменять конфигурацию 'default', поиск по словоформам может быть недоступен (но по абсолютно точному совпадению с шаблоном работать будет).
В таком случае триггер не нужен, для автозаполнения поля типа tsvector после каждого INSERT'а добавлять запрос:
UPDATE prefix_Post set fulltext_idx = to_tsvector('default_russian',coalesce(p_text,'') ||' '|| coalesce(p_title,'')) WHERE p_id=currval('prefix_Post_p_id_seq');
Такой запрос вернет документы с подсвеченными найденными словами, отсортированные по релевантности:
SELECT headline(p_text, to_tsquery('default_russian', 'слово1 & слово2')),
                 rank(fulltext_idx, to_tsquery('default_russian', 'слово1 & слово2')) as rank
FROM prefix_Post WHERE fulltext_idx @@ to_tsquery('default_russian','слово1 & слово2') order by rank desc;

Вариант с трггером,однако, предпочтительней, только при коннекте к базе нужно устанавливать конфигурацию 'derfault_russian', сразу после коннекта:

SET client_encoding='win1251'  // на случай, если PHP5 работает с PostgreSQL так же,как и с MySQL
SELECT set_curcfg('default_russian')

В этом случае в поисковых запросах конфигурацию можно вообще не указывать:

SELECT headline(p_text, to_tsquery('слово1 & слово2')),
      rank(fulltext_idx, to_tsquery('слово1 & слово2')) as rank
      FROM prefix_Post WHERE fulltext_idx @@ to_tsquery('слово1 & слово2') order by rank desc;


По идее, запросы от клиента зависеть не должны...
Вопрос: а как быть с запросами вот такого вида:
SELECT u.*, ln.*, st.*, u__pmcount AS pmcount, u__warnings AS uw_count FROM( ib_User AS u, ib_Language AS ln, ib_StyleSet AS st )LEFT JOIN ib_LastVisit lv ON (lv.fid=0 AND lv.uid=u.u_id) WHERE ln.ln_id=u.u_lnid AND st.st_id=u.u_stid

PostgreSQL начинает ругаться на то, что таблицы из FROM( в )LEFT JOIN использовать нельзя:

ERROR: invalid reference to FROM-clause entry for table "u"
ПОДСКАЗКА: There is an entry for table "u", but it cannot be referenced from this part of the query.