PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Разработване на PostgreSQL за Windows, част 2

В предишната публикация в блога обсъдихме различните варианти на компилация на Windows, които PostgreSQL поддържа. В тази публикация ще обсъдим как, като Unix-базиран разработчик, можете да проверите дали вашата корекция може да работи на Windows. (За простота ще кажа „Unix“, за да означава Linux, BSD, macOS и други подобни.)

Първо, има няколко начина да проверите корекцията си, без изобщо да имате Windows.

Ако корекцията ви докосне системата за изграждане, например чрез добавяне на нови файлове или по-вероятно чрез добавяне на условни условия, нови опции за изграждане или допълнителна ad-hoc логика, това може да наруши скриптовете за изграждане на MSVC, които анализират Unix make-файловете, както обсъдихме последен път. Но всъщност можете да стартирате тези скриптове и в Unix. В тях няма (почти) нищо специфично за Windows, тъй като всичко, което наистина правят, е да анализират един набор от файлове и да произвеждат друг. Можете просто да бягате

perl src/tools/msvc/mkvcbuild.pl

и вижте какво ще стане. Това работи от комит 73c8596. (Може би запишете работата си предварително, защото това може да презапише някои генерирани файлове, които да се използват от вашата локална конфигурация извън Windows). Това ще създаде проектни файлове за Visual Studio, с които не можете да правите много, но можете да проверите дали скриптът е работил изобщо, можете да сравните изхода преди и след, или ако сте направили „сляпо редакция“ на някой от файлове под src/tools/msvc/ можете да ги проверите до известна степен.

Друг начин е да упражнявате опции за изграждане, които обикновено са свързани с Windows. Кое от тях е полезно зависи от промените в пластира. Например Windows изгражда с HAVE_UNIX_SOCKETS undefined, така че ръчното тестване може да си струва, ако правите промени в мрежовия код. (Но това изчезва, тъй като Windows действително поддържа сокети на Unix домейн сега.) По същия начин, HAVE_WORKING_LINK е недефиниран в Windows, въпреки че въздействието от това е малко (и също изчезва; понякога следствие от писането на публикации в блог като тази е да откриете, че проблемите, които искате да опишете, не трябва да са там на първо място, и отиваш да ги оправиш). Можете да промените и двете опции, като редактирате src/include/pg_config_manual.h . Друга важна опция е EXEC_BACKEND , който заменя fork() в стил Unix извикване с fork() плюс exec() реализация, която може да бъде съпоставена с CreateProcess() на Windows. Това всъщност се счупва изненадващо рядко, но ако се случи, можете да отстраните грешки и да го поправите изцяло в Unix система. За да активирате EXEC_BACKEND , можете да редактирате src/Makefile.global и добавете -DEXEC_BACKEND към CPPFLAGS , или може би добавете дефиниране към src/include/pg_config_manual.h . (Не съм сигурен защо това е различно от другите; може би още нещо, което трябва да се поправи някога. [актуализация:също коригирано])

Когато тези опции са изчерпани, тогава може би е време да завъртите истинска Windows система. Искам да обсъдя две опции, които са лесно достъпни за обикновения разработчик. Първо, можете да изтеглите демонстрационно изображение на Windows от Microsoft и да го импортирате във VirtualBox или нещо подобно. Текущите връзки за това, които мога да намеря, са:

  • https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
  • https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

Вторият от тях е предназначен за тестване на браузъри, така че може би първият е по-добър сега, но маршрутът за тестване на браузъра е популярен от известно време. Това са безплатни пробни копия, но моля, прочетете лиценза сами.

Второ, можете да стартирате облачен екземпляр при доставчик на облачни изчисления. Няма да ги назовавам, но знаете кои са.

Когато работите с операционната система Windows, препоръчвам да инсталирате MSYS2. (Първата връзка за изтегляне по-горе от Microsoft също има инсталиран Visual Studio, ако предпочитате това.) Използвайте браузър (вероятно Internet Explorer или както се казва сега), за да отидете на msys2.org, стартирайте инсталационната програма и след няколко минути ще има готова пълна среда MSYS2/MinGW. Следвайте инструкциите на уеб сайта msys2.org, за да актуализирате мениджъра на пакети. След това отворете обвивка MinGW (не MSYS2) от менюто "Старт" и стартирайте следното, за да получите пакетите, необходими за разработката на PostgreSQL:

pacman -S git

Сега можете git да клонирате хранилището. Докато това работи...

pacman -S ${MINGW_PACKAGE_PREFIX}-gcc ${MINGW_PACKAGE_PREFIX}-gettext ${MINGW_PACKAGE_PREFIX}-icu ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-til flexPACKAGE_PREFIX}-libx PACKAGE_PREFIX}-libxPACKAGE_PREFIX}-libxPACKAGE_PREFIX}-libxP 

MINGW_PACKAGE_PREFIX е променлива на средата, която е зададена за вас, така че въведете командите по този начин. (Това ще бъде различно за 32-битов и 64-битов MinGW.) Пакетите без префикс са MSYS2 (т.е. Cygwin) пакети. Вижте част 1 отново, ако това е объркващо. В този момент ще имате пълна среда за изграждане на MinGW за PostgreSQL. Можете да стартирате configure, make, make check и т.н. Може да са необходими допълнителни пакети за някои опции за изграждане, но не всички опции действително работят; например без Readline (използвайте Cygwin за това).

В следващата част от тази серия ще разгледам опциите за автоматично изграждане/непрекъсната интеграция за Windows, които могат да се използват за проверка на корекции.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Намерете записи, където присъединяването не съществува

  2. Как да сравните производителността на PostgreSQL с помощта на Sysbench

  3. базата данни за преименуване на postgres не работи

  4. Как да използвам схеми в Django?

  5. Шаблони и модификатори за числово форматиране в PostgreSQL