postgres - możliwości
Wojciech Talaga - 14-09-2006 00:09
postgres - możliwości
witam!
Dostałem listę problemów/tematów zwiazanych z bazami danych i
musze określić czy dana rzecz jest obsługiwana w postgresie czy też nie.
Googlalem i googlalem, przeglądałem dokumentację postgresa i mimo tego na
niektóre z nich mam problemy z odpowiedzią, albo nie jestem do końca
pewien. Może będzie umiał mi ktoś z Was pomóc. Z góry wielkie dzięki!
Oto one:
1. Możliwość zagnieżdżania transakcji, powinna istnieć możliwość
uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej.
Przykładowo powinien być możliwy następujący scenariusz: każda próba
modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w tabeli
dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona
czy wycofana,
2 Wsparcie dla procedur i funkcji składowanych w bazie danych. Język
programowania powinien być językiem proceduralnym, blokowym (umożliwiającym
deklarowanie zmiennych wewnątrz bloku) oraz posiadającym mechanizmy obsługi
wyjątków wbudowane w konstrukcję języka. Procedury i funkcje powinny mieć
możliwość parametryzowania za pomocą parametrów prostych jak i parametrów o
typach złożonych, definiowanych przez użytkownika. Ww. jednostki programowe
powinny umożliwiać wywoływanie instrukcji SQL (zapytania, instrukcje DML,
DDL), wspierać mechanizm kursorów oraz wspierać mechanizmy transakcyjne
(np. zatwierdzanie bądź wycofanie transakcji wewnątrz procedury/funkcji),
3. Baza danych powinna pozwalać na wymuszanie złożoności hasła użytkownika,
czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez
administratora bądź w przypadku przekroczenia limitu nieudanych logowań,
4. Przywileje użytkowników bazy danych powinny być określane za pomocą
przywilejów systemowych (np. prawo do podłączenia się do bazy danych -
czyli utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów
dostępu do obiektów aplikacyjnych (np. odczytu / modyfikacji tabeli,
wykonania procedury). Baza danych powinna umożliwiać nadawanie ww.
przywilejów za pośrednictwem mechanizmu grup użytkowników / ról
bazodanowych,
5. Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML
(INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza
modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych
(np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba
zalogowania użytkownika),
6. Wbudowana obsługa wyrażeń regularnych zgodna ze standardem POSIX dostępna
z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych,
7. Możliwość zaimplementowania polityki bezpieczeństwa regulującej dostęp do
danych na poziomie pojedynczych wierszy w tabelach. Mechanizm ten powinien
być realizowany za pomocą mechanizmów motoru bazy danych i powinien być
przezroczysty dla aplikacji,
8. Motor bazy danych powinien udostępniać możliwość zrównoleglenia operacji
SQL (zapytania, instrukcje DML, ładowanie danych, tworzenie indeksów,
przenoszenie tabel/indeksów pomiędzy przestrzeniami danych) oraz procesów
wykonywania kopii bezpieczeństwa bądź odtwarzania,
9. Umożliwienie wymuszenia zastosowania przez optymalizator SQL metody
wskazanej przez administratora bazy danych. Możliwość profilowania
instrukcji SQL przez motor bazy danych. Uzyskany rezultat profilowania może
być zapisany w repozytorium bazy danych oraz wykorzystany przez
optymalizator do optymalizacji zapytań bez wprowadzania zmian do tekstu
instrukcji SQL,
10. Możliwość zarządzania przydziałem zasobów obliczeniowych dla
użytkowników bazy danych,
11. Możliwość kompresji danych w tabelach stopień kompresji powinien być
zależny od powtarzalności wartości atrybutów w wierszach,
12. Możliwość automatycznego zarządzania danymi sumarycznymi składowanymi w
migawkach. Odświeżanie migawek powinno być możliwe na żądanie lub w czasie
zatwierdzania zmian danych źródłowych, na których jest oparta migawka
zawierająca dane sumaryczne. Zapytania SQL powinny mieć możliwość
automatycznego wykorzystania danych sumarycznych zawartych w migawkach
zamiast wykonywania dostępu do danych źródłowych bez konieczności
modyfikowania ich tekstu. Ponadto, w przypadkach, gdy migawka zawiera
nieaktualne podsumowanie, powinny być odpytywane dane źródłowe.
--
pozdrawiam
woyciech
Michał Kuratczyk - 14-09-2006 00:09
Wojciech Talaga wrote:
> Dostałem listę problemów/tematów zwiazanych z bazami danych i
> musze określić czy dana rzecz jest obsługiwana w postgresie czy też nie.
Wygląda mi to na SIWZ do przetargu. Według mnie można go streścić
słowami "chcemy Oracle". PostgreSQL nie spełnia niektórych wymagań (np.
commit/rollback wewnątrz procedur; w każdym razie do niedawna tego nie
miał), a Oracle spełnia wszystkie wymagania. Nie wiem jak inne "duże" (DB2,
SQL Server), ale znając życie autor się o to "zatroszczył" (w sensie każdy
inny nie spełnia przynajmniej jednego wymagania), ale to już tylko moja
mała teoria spiskowa.
--
Michał Kuratczyk
Wojciech Talaga - 14-09-2006 00:09
Michał Kuratczyk wrote:
>> Dostałem listę problemów/tematów zwiazanych z bazami danych i
>> musze określić czy dana rzecz jest obsługiwana w postgresie czy też nie.
> Wygląda mi to na SIWZ do przetargu. Według mnie można go streścić
> słowami "chcemy Oracle". PostgreSQL nie spełnia niektórych wymagań (np.
> commit/rollback wewnątrz procedur; w każdym razie do niedawna tego nie
> miał), a Oracle spełnia wszystkie wymagania. Nie wiem jak inne "duże"
> (DB2, SQL Server), ale znając życie autor się o to "zatroszczył" (w sensie
> każdy inny nie spełnia przynajmniej jednego wymagania), ale to już tylko
> moja mała teoria spiskowa.
Też tak mi się wydaje, że są to po prostu możliwości jednego z systemów
bazodanowych. Ale interesuje mnie to czy jakiekolwiek z tych zagadanień
obsługuje Postgres?
--
pozdrawiam
woyciech
Mikolaj Rydzewski - 14-09-2006 00:09
Wojciech Talaga <woyciech@klub.chip.pl> wrote:
> Dostałem listę problemów/tematów zwiazanych z bazami danych i
> musze określić czy dana rzecz jest obsługiwana w postgresie czy też nie.
> Googlalem i googlalem, przeglądałem dokumentację postgresa i mimo tego na
> niektóre z nich mam problemy z odpowiedzią, albo nie jestem do końca
> pewien. Może będzie umiał mi ktoś z Was pomóc. Z góry wielkie dzięki!
Chcesz zebysmy odrobili za ciebie zadanie? Napisz do jakich wnioskow
doszedles, wtedy na pewno znajdzie sie ktos kto sprostuje.
Na niektore pytania odpowiedzi zawarte sa wprost w dokumentacji, chyba
niezbyt dokladnie ja czytales.
--
Mikolaj Rydzewski <miki@ceti.pl> http://ceti.pl/~miki/
PGP KeyID: 8b12ab02
There are three kinds of people: men, women, and unix.
Wojciech Talaga - 14-09-2006 00:09
Mikolaj Rydzewski wrote:
> Chcesz zebysmy odrobili za ciebie zadanie? Napisz do jakich wnioskow
> doszedles, wtedy na pewno znajdzie sie ktos kto sprostuje.
Oki to są moje wnioski...
1. Możliwość zagnieżdżania transakcji, powinna istnieć możliwość
uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej.
Przykładowo powinien być możliwy następujący scenariusz: każda próba
modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w tabeli
dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona
czy wycofana,
Niestety tutaj nie wiem...
2 Wsparcie dla procedur i funkcji składowanych w bazie danych. Język
programowania powinien być językiem proceduralnym, blokowym (umożliwiającym
deklarowanie zmiennych wewnątrz bloku) oraz posiadającym mechanizmy obsługi
wyjątków wbudowane w konstrukcję języka. Procedury i funkcje powinny mieć
możliwość parametryzowania za pomocą parametrów prostych jak i parametrów o
typach złożonych, definiowanych przez użytkownika. Ww. jednostki programowe
powinny umożliwiać wywoływanie instrukcji SQL (zapytania, instrukcje DML,
DDL), wspierać mechanizm kursorów oraz wspierać mechanizmy transakcyjne
(np. zatwierdzanie bądź wycofanie transakcji wewnątrz procedury/funkcji),
Tak? PL/pgSQL ?
3. Baza danych powinna pozwalać na wymuszanie złożoności hasła użytkownika,
czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez
administratora bądź w przypadku przekroczenia limitu nieudanych logowań,
Czas życia hasła tak, ale wymuszanie długości i blokowanie dostępu przy
kilku próbach to raczej nie. Mam rację?
4. Przywileje użytkowników bazy danych powinny być określane za pomocą
przywilejów systemowych (np. prawo do podłączenia się do bazy danych -
czyli utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów
dostępu do obiektów aplikacyjnych (np. odczytu / modyfikacji tabeli,
wykonania procedury). Baza danych powinna umożliwiać nadawanie ww.
przywilejów za pośrednictwem mechanizmu grup użytkowników / ról
bazodanowych,
Tutaj nie bardzo rozumiem o co chodzi. Postgres umożliwia nadawanie ról
użytkownikom (superużytkownik, tworzenie tabel, tworzenie ról itp)
Z kolei grup uzytkowników to chyba w Postgresie nie można robić?
5. Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML
(INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza
modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych
(np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba
zalogowania użytkownika),
wydaje się, że tak.
6. Wbudowana obsługa wyrażeń regularnych zgodna ze standardem POSIX dostępna
z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych,
Tu również, że tak.
7. Możliwość zaimplementowania polityki bezpieczeństwa regulującej dostęp do
danych na poziomie pojedynczych wierszy w tabelach. Mechanizm ten powinien
być realizowany za pomocą mechanizmów motoru bazy danych i powinien być
przezroczysty dla aplikacji,
Nie?
8. Motor bazy danych powinien udostępniać możliwość zrównoleglenia operacji
SQL (zapytania, instrukcje DML, ładowanie danych, tworzenie indeksów,
przenoszenie tabel/indeksów pomiędzy przestrzeniami danych) oraz procesów
wykonywania kopii bezpieczeństwa bądź odtwarzania,
Nie?
9. Umożliwienie wymuszenia zastosowania przez optymalizator SQL metody
wskazanej przez administratora bazy danych. Możliwość profilowania
instrukcji SQL przez motor bazy danych. Uzyskany rezultat profilowania może
być zapisany w repozytorium bazy danych oraz wykorzystany przez
optymalizator do optymalizacji zapytań bez wprowadzania zmian do tekstu
instrukcji SQL,
Nie mam bladego pojęcia...
10. Możliwość zarządzania przydziałem zasobów obliczeniowych dla
użytkowników bazy danych,
Nie?
11. Możliwość kompresji danych w tabelach stopień kompresji powinien być
zależny od powtarzalności wartości atrybutów w wierszach,
Nie?
12. Możliwość automatycznego zarządzania danymi sumarycznymi składowanymi w
migawkach. Odświeżanie migawek powinno być możliwe na żądanie lub w czasie
zatwierdzania zmian danych źródłowych, na których jest oparta migawka
zawierająca dane sumaryczne. Zapytania SQL powinny mieć możliwość
automatycznego wykorzystania danych sumarycznych zawartych w migawkach
zamiast wykonywania dostępu do danych źródłowych bez konieczności
modyfikowania ich tekstu. Ponadto, w przypadkach, gdy migawka zawiera
nieaktualne podsumowanie, powinny być odpytywane dane źródłowe.
migawki = dumpy ?? jak to rozumieć?
raczej nie ma tego postgres...
--
--
pozdrawiam
woyciech
Michał Kuratczyk - 14-09-2006 00:09
Wojciech Talaga wrote:
> 2 Wsparcie dla procedur i funkcji składowanych w bazie danych. Język
> programowania powinien być językiem proceduralnym, blokowym
> (umożliwiającym deklarowanie zmiennych wewnątrz bloku) oraz posiadającym
> mechanizmy obsługi wyjątków wbudowane w konstrukcję języka. Procedury i
> funkcje powinny mieć możliwość parametryzowania za pomocą parametrów
> prostych jak i parametrów o typach złożonych, definiowanych przez
> użytkownika. Ww. jednostki programowe powinny umożliwiać wywoływanie
> instrukcji SQL (zapytania, instrukcje DML, DDL), wspierać mechanizm
> kursorów oraz wspierać mechanizmy transakcyjne (np. zatwierdzanie bądź
> wycofanie transakcji wewnątrz procedury/funkcji),
>
> Tak? PL/pgSQL ?
O ile wiem nie spełnia ostatniego wymagania - commit/rollback.
> 12. Możliwość automatycznego zarządzania danymi sumarycznymi składowanymi
> w migawkach. Odświeżanie migawek powinno być możliwe na żądanie lub w
> czasie zatwierdzania zmian danych źródłowych, na których jest oparta
> migawka zawierająca dane sumaryczne. Zapytania SQL powinny mieć możliwość
> automatycznego wykorzystania danych sumarycznych zawartych w migawkach
> zamiast wykonywania dostępu do danych źródłowych bez konieczności
> modyfikowania ich tekstu. Ponadto, w przypadkach, gdy migawka zawiera
> nieaktualne podsumowanie, powinny być odpytywane dane źródłowe.
>
> migawki = dumpy ?? jak to rozumieć?
> raczej nie ma tego postgres...
Raczej nie ma, a chodzi o to, co w Oracle nazywa się materialized views.
O ile wiem podobny feature mają DB2 i SQL Server, ale pod jakimiś innymi
nazwzami (i nie wiem czy spełniają wszystkie podwymagania).
--
Michał Kuratczyk
ethanak - 14-09-2006 00:09
On 2006-09-13 13:36, Wojciech Talaga wrote:
[...]
Tak z czystej ciekawości - po co Ci to?
ethanak
--
mailto=window.atob('ZXRoYW5ha0Bwb2xpcC5jb20=');
Michał Zaborowski - 14-09-2006 00:09
Dnia 2006-09-13 14:47, Użytkownik Wojciech Talaga napisał:
> Mikolaj Rydzewski wrote:
>
>> Chcesz zebysmy odrobili za ciebie zadanie? Napisz do jakich wnioskow
>> doszedles, wtedy na pewno znajdzie sie ktos kto sprostuje.
>
> Oki to są moje wnioski...
>
> 1. Możliwość zagnieżdżania transakcji, powinna istnieć możliwość
> uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej.
> Przykładowo powinien być możliwy następujący scenariusz: każda próba
> modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w tabeli
> dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona
> czy wycofana,
>
> Niestety tutaj nie wiem...
>
To wygląda jak opis działania transakcji w Oracle. Nie siedzę w
Oracle na tyle, żeby źródło podać... Wszystko co można zaproponować
to savepoint.
Ad 2 - to już jest omówione...
> 3. Baza danych powinna pozwalać na wymuszanie złożoności hasła użytkownika,
> czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez
> administratora bądź w przypadku przekroczenia limitu nieudanych logowań,
>
> Czas życia hasła tak, ale wymuszanie długości i blokowanie dostępu przy
> kilku próbach to raczej nie. Mam rację?
>
Da się to zrobić - np. ustawić autoryzację zewnętrzną...
> 4. Przywileje użytkowników bazy danych powinny być określane za pomocą
> przywilejów systemowych (np. prawo do podłączenia się do bazy danych -
> czyli utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów
> dostępu do obiektów aplikacyjnych (np. odczytu / modyfikacji tabeli,
> wykonania procedury). Baza danych powinna umożliwiać nadawanie ww.
> przywilejów za pośrednictwem mechanizmu grup użytkowników / ról
> bazodanowych,
>
Tu to samo co w 3 w części dotyczącej przywilejów systemowych. Reszta
jest.
> Z kolei grup uzytkowników to chyba w Postgresie nie można robić?
>
Role są, help też... ;)
> 5. Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML
> (INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza
> modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych
> (np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba
> zalogowania użytkownika),
>
> wydaje się, że tak.
>
Mi się "wydaje", że nie. Chodzi o to, że Oracle ma np. trigger
onCommit. Przydaje się np. materialized views, ale da się zrobić
bez tego.
> 6. Wbudowana obsługa wyrażeń regularnych zgodna ze standardem POSIX dostępna
> z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych,
>
> Tu również, że tak.
>
Tak - operator ~
> 7. Możliwość zaimplementowania polityki bezpieczeństwa regulującej dostęp do
> danych na poziomie pojedynczych wierszy w tabelach. Mechanizm ten powinien
> być realizowany za pomocą mechanizmów motoru bazy danych i powinien być
> przezroczysty dla aplikacji,
>
> Nie?
>
Tak? :) No w każdym razie... Jest coś takiego jak "instead of"
zamiast zwykłego selecta można wykonać takiego, który ma ograniczenie
dla użytkownika. Nie jest to rozwiązanie polecane, bo każdy select
będzie miał ten "dodatek".
> 8. Motor bazy danych powinien udostępniać możliwość zrównoleglenia operacji
> SQL (zapytania, instrukcje DML, ładowanie danych, tworzenie indeksów,
> przenoszenie tabel/indeksów pomiędzy przestrzeniami danych) oraz procesów
> wykonywania kopii bezpieczeństwa bądź odtwarzania,
>
> Nie?
>
Nie. Dla przykładu PG jest jeden proces, który przenosi dane z cache
na dysk. W Oracle można to zrównoleglić.
> 9. Umożliwienie wymuszenia zastosowania przez optymalizator SQL metody
> wskazanej przez administratora bazy danych. Możliwość profilowania
> instrukcji SQL przez motor bazy danych. Uzyskany rezultat profilowania może
> być zapisany w repozytorium bazy danych oraz wykorzystany przez
> optymalizator do optymalizacji zapytań bez wprowadzania zmian do tekstu
> instrukcji SQL,
>
> Nie mam bladego pojęcia...
>
To jest mechanizm z Oracle. Jak tekst zapytania się nie zmienił silnik
pamięta jakiego planu użył i poprostu go używa. Jest też coś takiego jak
'hint' - dodaje się specjalny komentarz, który wymusza np. użycie
indeksu. W PG od biedy można stosować 'set enable_seqscan to off', ale
to trochę nie to samo...
> 10. Możliwość zarządzania przydziałem zasobów obliczeniowych dla
> użytkowników bazy danych,
>
> Nie?
>
Nie. Nie znam innej bazy, poza Oracle, która umożliwia powiedzenie, że
np. dyrektor ma zagwarantowane nie mniej niż 50% mocy obliczeniowej 3
procesora. Przydaje się przy obciążonej bazie danych i pieklącym się
dyrektorze :)
> 11. Możliwość kompresji danych w tabelach stopień kompresji powinien być
> zależny od powtarzalności wartości atrybutów w wierszach,
>
> Nie?
>
Z tym stopniem kompresji to nie wiem o co chodzi. Ogólnie tak, w PG
jest możliwa kompresja od wersji 7.1 AFAIR.
> 12. Możliwość automatycznego zarządzania danymi sumarycznymi składowanymi w
> migawkach. Odświeżanie migawek powinno być możliwe na żądanie lub w czasie
> zatwierdzania zmian danych źródłowych, na których jest oparta migawka
> zawierająca dane sumaryczne. Zapytania SQL powinny mieć możliwość
> automatycznego wykorzystania danych sumarycznych zawartych w migawkach
> zamiast wykonywania dostępu do danych źródłowych bez konieczności
> modyfikowania ich tekstu. Ponadto, w przypadkach, gdy migawka zawiera
> nieaktualne podsumowanie, powinny być odpytywane dane źródłowe.
>
> migawki = dumpy ?? jak to rozumieć?
> raczej nie ma tego postgres...
>
Chodzi o materialized views, jak zostało to już powiedziane przez
mojego imiennika. ;) A to artykuł jak takie rzeczy można zrobić w PG:
http://jonathangardner.net/PostgreSQ.../matviews.html
Jak napisałem wcześniej przydaje się mieć trigger on commit - wtedy
można odpowiednio zareagować na zmianę. Chodzi o to, że jak w dwóch
transakcjach jest zmiana tej samej wartości to może być problem, bo
transakcje nie widzą się wzajemnie (w ogólnym przypadku) i wyliczą
wartość na podstawie dostępnych danych - czyli co by się nie stało
wynik będzie błędny. Użycie 'dirty read' też nie rozwiązuje problemu,
bo transakcja może zostać anulowana...
Nie wiem czego to dotyczy, ale ja bym się zapytał po co komuś to
wszystko. Z mojej perspektywy to ja mam coś wykonać i to moja sprawa
jak. Co za różnica, czy będzie np. zarządzanie tym czy tamtym, skoro
można zrobić tak, że cały dostęp będzie realizowany przez procedury?
To uwaga ogólna - tak samo można zrobić np. w MS SQL Serwerze
--
Pozdrawiam,
Michał Zaborowski (TeXXaS)
Grzesiek G. - 11-11-2006 00:51
Michał Kuratczyk napisał(a):
> Wojciech Talaga wrote:
>
>>Dostałem listę problemów/tematów zwiazanych z bazami danych i
>>musze określić czy dana rzecz jest obsługiwana w postgresie czy też nie.
>
> Wygląda mi to na SIWZ do przetargu. Według mnie można go streścić
> słowami "chcemy Oracle".
[...]
Odniosłem dokładnie takie samo wrażenie czytając post :-).
Pozdrawiam
--
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!
Tomasz Judycki - 11-11-2006 00:52
Wojciech Talaga <woyciech@klub.chip.pl> napisał(a):
> witam!
>
> Dostałem listę problemów/tematów zwiazanych z bazami danych i
> musze określić czy dana rzecz jest obsługiwana w postgresie czy też nie.
> Googlalem i googlalem, przeglądałem dokumentację postgresa i mimo tego na
> niektóre z nich mam problemy z odpowiedzią, albo nie jestem do końca
> pewien. Może będzie umiał mi ktoś z Was pomóc. Z góry wielkie dzięki!
> Oto one:
Jeśli to jest fragment SIWZu i z pełnej listy kryteriów wynika, że spełnia je
tylko np. Oracle to radzę albo oprotestować specyfikację albo dać sobie spokój
z tym przetargiem.
tj
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[PostgreSQL] - jak =?ISO-8859-2?Q?zabezpieczy=E6_interesy_tw?==?ISO-8859-2?Q?=F3rcy_systemu_=3F=3F=3F?=
postgresql - int/int
postgresql Select count(*) czy raczej Select count(ID)
[PostgreSQL] jak =?ISO-8859-2?Q?pobra=E6_warto=B6=E6_zwracan?==?ISO-8859-2?Q?=B1_przez_funkcj=EA=3F?=
[postgresql] INSERT OR UPDATE - jak =?ISO-8859-2?Q?b=EAdzie_na?==?ISO-8859-2?Q?jlepiej=3F?=
[postgresql] kilka =?ISO-8859-2?Q?rekord=F3w_subquery_jako_?==?ISO-8859-2?Q?string?=
[PostgreSQL] Jak =?ISO-8859-2?Q?po=B3=B1czy=E6_funkcje_z_w?==?ISO-8859-2?Q?idokiem?=
Postgres - replikcja master-master
Dopasowanie do "najlepszego" dopasowania :) [ PostgreSQL]
Problemy z =?ISO-8859-2?Q?instalacj=B1_PostgreSQL_na_syste?==?ISO-8859-2?Q?mach_Windows?=
zanotowane.pldoc.pisz.plpdf.pisz.plbajkomoda.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
