Два въпроса за PostgreSQL

1. Защо при мен нямам вградена функцията md5(), както е описана тук? Версията, която използвам е 7.3.6 - последното binary от PowerGres за Windows.

select * from pg_proc where proname='md5'; връща 0 реда.

2. Ако искам да имам таблица с primary key със сравнително малко стойности в нея (десетина), как е по-добре да го дефинирам: със стандартния serial тип или с изрично създаване на sequence - и във втория случай: да използвам smallint или numeric(1)?

Everything louder than everything else...

относно
1. PowerGres не съм виждал, защо ползваш него? това ли ще е работещата версия после? искам да кажа за дев, cygwin версията не ти ли върши работа, (там май си идва md5) или пък бета версията на 8 (нея за windows обаче също не съм я виждал).
незнам за какво точно ще ползваш md5, но разгледай pgcrypto, пакета от contrib, там има доста голямо разнообразие от функции, които може да са ти полезни (незнам дали идва с PowerGres)

изобщо по тоз въпрос - много май и или съм ползвал ;-))

2. разгледай [линк]
мисял, че сам ще си отговориш ;-) т.е. аз лично не бих ползвал smallint

1. Само dev е естествено, а не съм се пробвал през cygwin, защото доколкото съм чувал е доста играчка...но май ще си поиграя. MD5 конкретно ми трябва за хеширане на пароли - за момента и в php мога да си го правя, но не се знае още колко "изненади" ме чакат, така че или ще switch-на на 8 или през cygwin.

2. Това го прочетох вече и именно по тази причина питам за практически съвет. В този контекст, щом не би ползвал smallint, кое от двете остава: serial или sequence + numeric(1)?

Май има още въпроси, но засега и това ще ми е от полза...благодаря.

P.S.: И все пак, има ли някакъв начин при неизпълнено условие на CONSTRAINT, SEQUENCE-а да не се увеличава?

Everything louder than everything else...

cygwin, не е чак такава играчка ....
(за пароли може да ползваш dbcrypt)

ако numeric(1) ти е достатъчен, то никъв индекс не трябва на полето и тогава ползвай каквото си искаш ;-) то и sequence е доста пресилено да ползваш в такъв случай ....

за послеслова - не може (но какъв ти е проблема :-) ако чак толко се терзаеш - може да се мине през някъв тригер и ще стане работата, ама .... )

и пак за последното - може и без тригер, но през функциика, която си направиш сам (но внимателно ;-)) но пак не виждам чак такъв зор

(по принцип, ако нещо може да стане без тригери, аз предпочитам да стане без тригери ;-))

Ми работата е там, че при неуспешен INSERT, заради някакъв constraint примерно, sequence-а все пак се увеличава - това не ми представлява проблем, но просто ми изглежда странно - уж нищо не се записва, пък ID-то изведнъж прескача с 10 позиции. Осъзнвам, че извикването към sequence-а се извършва преди да се пристъпи към самото записване, но пък от потребителска гледна точка ми се струва нормално да се извърши някакъв вид ROLLBACK - да се върне sequence-а в старото му положение. Но чак зор не ми е...просто се адаптирам какво да очаквам за в бъдеще.

Съвсем конкретно - опитвам се да запиша нов потребител в таблица "user" като username-а е UNIQUE. В MySQL го правя с INSERT IGNORE и после проверявам mysql_affected_rows и евентуално връщам "User X already exists." - по този начин си спестявам един SELECT. И просто искам да направя същото в PostgreSQL - само дето pg_affected_rows иска за параметър result, а такъв няма, защото pg_query е върнало false...и така стигам до въпроса за парсването на грешката, който зададох в PHP клуба.

P.S.: А ако е numeric(2) или (3)...изобщо, има ли проблем с индексирането върху numeric полета?

Everything louder than everything else...

проблем с индексирането на numeric няма, но то е просто по-бавно от integer

ами с този проблем, дет си описал, не виждам никъв проблем ;-))

if (!pg_query("insert ...")){
echo 'ima takav potrebitel';
}

ако искаш да си сигурен защо е гръмнало, проверяваш грешката не с pg_result_error :-) както писах там ;-)) и то си е съвсем същото като MySQL

а не се връща брояча (sequence-то) щото има стандартният проблем - ако в тоз момент друг инсъртва, той ще гепи по-горен номер и то докато се върне (броячите могат да се ползват по-доста по-сложни начини във функции и други и няма как да се застраховат без lock) ...... (както казах с функция може да си реализираш собствен брояч със заключване и може да постигнеш непрекъснатост)

Дааа...май нещата почват да се проясняват. Явно върху самия sequence няма MVCC, а само върху редовете в таблицата.

Благодаря.

Everything louder than everything else...

мда тва откритие е добро ;-))

Не е специфичен за PostgreSQL а въобще за работата с транзакции.

Ако речем, че съвсем теоретично имаш 2 транзакции и следната последователност в някакъв мета език:

a = 0

tx1: START

tx1: <a = NEW value>

tx2: START

tx2: <a = NEW value>

tx1: ROLLBACK

tx2: COMMIT

Какъвто и да е алгоритъма за нова стойност имаш само два възможни варианта:

А) С изключително заключване при което tx2 ще трябва за чака за да разбере дали tx1 ще приключи с COMMIT или не

Б) Получаваш дупки.


Очевидно A) ще е значително по-бавно при конкурентна работа и при положение, че дупките в добре проектирана структура рядко са проблем мисля е ясно защо Б) е "по подразбиране"

И понеже на няколко пъти цитираш MySQL - при InnoDB таблици с auto_increment проблемът е точно същия

salle.online.bg/sig

Доколкото знам InnoDB също както PostgreSQL и Oracle използва MVCC, така че от там идва всичко - както казваш има 2 варианта и бидейки във вариант Б, където няма lock, неминуемо стават дупки.

Everything louder than everything else...

Малко късно се включвам в темата, но както каза salle проблемът е принципен.
Основният проблем е "пречат ли на някого дупките?". Представи си, че ти се наложи да изтриеш запис от таблицата. Макар и да си бил перфектен с подреждането, то дупка пак ще остане. С локове вероятно става, но според мен няма смисъл. Ако някой пише софтуер за статистика на олимпиада, може би има смисъл да се замисли човек, но при положение, че ми е ясна "мащабността" на проектите в БГ, едва ли?
И без тва всеки ден караме из дупки, трябва да сме им свикнали вече!