--- /dev/null
+
+ PostgreSQL ³£¼ûÎÊÌ⣨FAQ£©
+
+ ×î½ü¸üУº2005 Äê 06 Ô 02 ÈÕ ÐÇÆÚÎå 22:27:35 CST
+
+
+ ±¾ÎĵµµÄ×îа汾¿ÉÒÔÔÚ
+ http://www.postgresql.org/files/documentation/faqs/FAQ.html²é¿´¡£
+
+ Óë²Ù×÷ϵͳƽ̨Ïà¹ØµÄÎÊÌâÔÚhttp://www.postgresql.org/docs/faq/Àï»Ø´ð¡£
+ _________________________________________________________________
+
+³£¼ûÎÊÌâ
+
+ 1.1)PostgreSQL ÊÇʲô£¿¸ÃÔõô·¢Òô£¿
+ 1.2)PostgreSQL µÄ°æȨÊÇʲô£¿
+ 1.3)PostgreSQL ¿ÉÒÔÔËÐÐÔÚÄÄЩ²Ù×÷ϵͳƽ̨ÉÏ£¿
+ 1.4)ÎÒ´ÓÄÄÀïÄܵõ½ PostgreSQL£¿
+ 1.5)ÎÒ´ÓÄÄÀïÄܵõ½¶Ô PostgreSQL µÄÖ§³Ö£¿
+ 1.6)ÎÒÈçºÎÌá½»Ò»¸öBUG±¨¸æ£¿
+ 1.7)×îаæµÄPostgreSQL ÊÇʲô£¿
+ 1.8)Äܹ»»ñÈ¡µÄ×îÐÂÎĵµÓÐÄÄЩ£¿
+ 1.9)ÎÒÈçºÎÁ˽âÒÑÖªµÄ BUG »òÔÝȱµÄ¹¦ÄÜ£¿
+ 1.10)ÎÒÓ¦¸ÃÔõÑùѧϰ SQL £¿
+ 1.11)ÎÒÓ¦¸ÃÔõÑù¼ÓÈ뿪·¢¶ÓÎ飿
+ 1.12)PostgreSQL ºÍÆäËûÊý¾Ý¿âϵͳ±ÈÆðÀ´ÈçºÎ£¿
+ 1.13)Ë¿ØÖƺ͹ÜÀíPostgreSQL £¿
+
+Óû§¿Í»§¶ËÎÊÌâ
+
+ 2.1)ÎÒÃÇ¿ÉÒÔÓÃʲôÓïÑÔºÍ PostgreSQL ´ò½»µÀ£¿
+ 2.2)ÓÐʲô¹¤¾ß¿ÉÒÔ°Ñ PostgreSQL ÓÃÓÚ Web Ò³Ã棿
+ 2.3)PostgreSQL ÓµÓÐͼÐÎÓû§½çÃæÂð£¿
+
+ϵͳ¹ÜÀíÎÊÌâ
+
+ 3.1)ÎÒÔõÑù²ÅÄÜ°Ñ PostgreSQL ×°ÔÚ /usr/local/pgsql ÒÔÍâµÄµØ·½£¿
+ 3.2)ÎÒÈçºÎ¿ØÖÆÀ´×ÔÆäËûÖ÷»úµÄÁ¬½Ó£¿
+ 3.3)ÎÒÔõÑùµ÷ÕûÊý¾Ý¿âÒýÇæÒÔ»ñµÃ¸üºÃµÄÐÔÄÜ£¿
+ 3.4)PostgreSQL Àï¿ÉÒÔ»ñµÃʲôÑùµÄµ÷ÊÔÌØÐÔ£¿
+ 3.5)ΪʲôÔÚÊÔͼÁ¬½ÓµÇ¼ʱÊÕµ½¡°Sorry, too many clients¡± ÏûÏ¢£¿
+ 3.6)ΪʲôҪÔÚÉý¼¶ PostgreSQL Ö÷Òª·¢²¼°æ±¾Ê±×ö dump ºÍ restore £¿
+ 3.7)(ʹÓÃPostgreSQL)ÎÒÐèҪʹÓÃʲô¼ÆËã»úÓ²¼þ £¿
+
+²Ù×÷ÎÊÌâ
+
+ 4.1)ÈçºÎֻѡÔñÒ»¸ö²éѯ½á¹ûµÄÍ·¼¸ÐУ¿»òÊÇËæ»úµÄÒ»ÐУ¿
+ 4.2)ÈçºÎ²é¿´±í¡¢Ë÷Òý¡¢Êý¾Ý¿âÒÔ¼°Óû§µÄ¶¨Ò壿ÈçºÎ²é¿´psqlÀïÓõ½µÄ²éѯָ
+ Áî²¢ÏÔʾËüÃÇ£¿
+ 4.3)ÈçºÎ¸ü¸ÄÒ»¸ö×ֶεÄÊý¾ÝÀàÐÍ£¿
+ 4.4)Ò»ÐмǼ£¬Ò»¸ö±í£¬Ò»¸ö¿âµÄ×î´ó³ß´çÊǶàÉÙ£¿
+ 4.5)´æ´¢Ò»¸öµäÐ͵ÄÎı¾ÎļþÀïµÄÊý¾ÝÐèÒª¶àÉÙ´ÅÅ̿ռ䣿
+ 4.6)ΪʲôÎҵIJéѯºÜÂý£¿ÎªÊ²Ã´ÕâЩ²éѯûÓÐÀûÓÃË÷Òý£¿
+ 4.7)ÎÒÈçºÎ²ÅÄÜ¿´µ½²éѯÓÅ»¯Æ÷ÊÇÔõÑùÆÀ¹À´¦ÀíÎҵIJéѯµÄ£¿
+ 4.8)ÎÒÔõÑù×öÕýÔò±í´ïʽËÑË÷ºÍ´óСдÎ޹صÄÕýÔò±í´ïʽ²éÕÒ£¿ÔõÑùÀûÓÃË÷Òý½ø
+ ÐдóСдÎ޹زéÕÒ£¿
+ 4.9)ÔÚÒ»¸ö²éѯÀÎÒÔõÑù¼ì²âÒ»¸ö×Ö¶ÎÊÇ·ñΪ
+ NULL£¿ÎÒÈçºÎ²ÅÄÜ׼ȷÅÅÐò¶ø²»ÂÛij×Ö¶ÎÊÇ·ñº¬NULLÖµ£¿
+ 4.10)¸÷ÖÖ×Ö·ûÀàÐÍÖ®¼äÓÐʲô²»Í¬£¿
+ 4.11.1)ÎÒÔõÑù´´½¨Ò»¸öÐòÁкÅ/×Ô¶¯µÝÔöµÄ×ֶΣ¿
+ 4.11.2)ÎÒÈçºÎ»ñµÃÒ»¸ö²åÈëµÄÐòÁкŵÄÖµ£¿
+ 4.11.3)ʹÓà currval() »áµ¼ÖºÍÆäËûÓû§µÄÎÉÂÒÇé¿ö£¨race condition£©Âð£¿
+ 4.11.4)Ϊʲô²»ÔÚÊÂÎñÒì³£ÖÐÖ¹ºóÖØÓÃÐòÁкÅÄØ£¿ÎªÊ²Ã´ÔÚÐòÁкÅ×ֶεÄÈ¡ÖµÖ
+ дæÔÚ¼ä¶ÏÄØ£¿
+ 4.12)ʲôÊÇ OID£¿Ê²Ã´ÊÇ CTID £¿
+ 4.13)ΪʲôÎÒÊÕµ½´íÎóÐÅÏ¢¡°ERROR: Memory exhausted in
+ AllocSetAlloc()¡±£¿
+ 4.14)ÎÒÈçºÎ²ÅÄÜÖªµÀËùÔËÐÐµÄ PostgreSQL µÄ°æ±¾£¿
+ 4.15)ÎÒÈçºÎ´´½¨Ò»¸öȱʡֵÊǵ±Ç°Ê±¼äµÄ×ֶΣ¿
+ 4.16)ÈçºÎ½øÐÐ outer join £¨ÍâÁ¬½Ó£©£¿
+ 4.17)ÈçºÎʹÓÃÉæ¼°¶à¸öÊý¾Ý¿âµÄ²éѯ£¿
+ 4.18)ÈçºÎÈú¯Êý·µ»Ø¶àÐлò¶àÁУ¿
+ 4.19)ΪʲôÎÒÔÚʹÓÃPL/PgSQLº¯Êý´æÈ¡ÁÙʱ±íʱ»áÊÕµ½´íÎóÐÅÏ¢¡°relation
+ with OID ##### does not exist¡±£¿
+ 4.20)Ä¿Ç°ÓÐÄÄЩÊý¾Ý¸´ÖÆ·½°¸¿ÉÓã¿
+ _________________________________________________________________
+
+³£¼ûÎÊÌâ
+
+ 1.1)PostgreSQL ÊÇʲô£¿¸ÃÔõô·¢Òô£¿
+
+ PostgreSQL ¶Á×÷ Post-Gres-Q-L£¬ÓÐʱºòÒ²¼ò³ÆΪPostgres ¡£
+
+ PostgreSQL
+ ÊÇÃæÏòÄ¿±êµÄ¹ØϵÊý¾Ý¿âϵͳ£¬Ëü¾ßÓд«Í³ÉÌÒµÊý¾Ý¿âϵͳµÄËùÓй¦ÄÜ£¬Í¬Ê±ÓÖ
+ º¬Óн«ÔÚÏÂÒ»´ú DBMS ϵͳµÄʹÓõÄÔöÇ¿ÌØÐÔ¡£ PostgreSQL
+ ÊÇ×ÔÓÉÃâ·ÑµÄ£¬²¢ÇÒËùÓÐÔ´´úÂ붼¿ÉÒÔ»ñµÃ¡£
+
+ PostgreSQL
+ µÄ¿ª·¢¶ÓÎéÖ÷ҪΪ־ԸÕߣ¬ËûÃDZ鲼ÊÀ½ç¸÷µØ²¢Í¨¹ý»¥ÁªÍø½øÐÐÁªÏµ£¬ÕâÊÇÒ»¸ö
+ ÉçÇø¿ª·¢ÏîÄ¿£¬Ëü²»±»Èκι«Ë¾¿ØÖÆ¡£
+ ÈçÏë¼ÓÈ뿪·¢¶ÓÎ飬Çë²Î¼û¿ª·¢ÈËÔ±³£¼ûÎÊÌ⣨FAQ£©
+ http://www.postgresql.org/files/documentation/faqs/FAQ_DEV.html
+
+ 1.2)PostgreSQL µÄ°æȨÊÇʲô?
+
+ PostgreSQLµÄ·¢²¼×ñ´Ó¾
+ µäµÄBSD°æȨ¡£¹ØÓÚÔ´´úÂëµÄÈçºÎʹÓÃûÓÐÈκÎÏÞÖÆ£¬ÎÒÃǺÜϲ»¶ÕâÖÖ·½Ê½²¢ÇÒ»
+ ¹Ã»ÓдòËã¸Ä±äËü¡£
+
+ ÏÂÃæ¾ÍÊÇÎÒÃÇʹÓõÄBSD°æȨÄÚÈÝ£º
+
+ ²¿·Ö°æȨ£¨c£©1996-2005£¬PostgreSQL
+ È«Çò¿ª·¢Ð¡×飬²¿·Ö°æȨ£¨c£©1994-1996 ¼ÓÖÝ´óѧ¶ÊÂ
+
+ £¨Portions copyright (c) 1996-2005, PostgreSQL Global Development
+ Group Portions Copyright (c) 1994-6 Regents of the University of
+ California£©
+
+ ÔÊÐíΪÈκÎÄ¿µÄʹÓ㬿½±´£¬Ð޸ĺͷַ¢Õâ¸öÈí¼þºÍËüµÄÎĵµ¶ø²»ÊÕÈ¡ÈκηÑÓÃ
+ £¬
+ ²¢ÇÒÎÞÐëÇ©ÊðÒò´Ë¶ø²úÉúµÄÖ¤Ã÷£¬Ç°ÌáÊÇÉÏÃæµÄ°æȨÉùÃ÷ºÍ±¾¶ÎÒÔ¼°ÏÂÃæÁ½¶ÎÎÄ
+ ×Ö³öÏÖÔÚËùÓп½±´ÖС£
+
+ £¨Permission to use, copy, modify, and distribute this software and
+ its documentation for any purpose, without fee, and without a written
+ agreement is hereby granted, provided that the above copyright notice
+ and this paragraph and the following two paragraphs appear in all
+ copies.£©
+
+ ÔÚÈκÎÇé¿öÏ£¬¼ÓÖÝ´óѧ¶¼²»³Ðµ£ÒòʹÓôËÈí¼þ¼°ÆäÎĵµ¶øµ¼ÖµĶÔÈκε±ÊÂÈË
+ µÄÖ±½ÓµÄ£¬
+ ¼ä½ÓµÄ£¬ÌØÊâµÄ£¬¸½¼ÓµÄ»òÕßÏà°é¶øÉúµÄË𻵣¬°üÀ¨ÀûÒæËðʧµÄÔðÈΣ¬¼´Ê¹¼ÓÖÝ
+ ´óѧÒѾ½¨ÒéÁËÕâЩËðʧµÄ¿ÉÄÜÐÔʱҲÊÇÈç´Ë¡£
+
+ £¨IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY
+ PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
+ DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS
+ SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA
+ HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.£©
+
+ ¼ÓÖÝ´óѧÃ÷È··ÅÆúÈκα£Ö¤£¬°üÀ¨µ«²»¾ÖÏÞÓÚijһÌض¨ÓÃ;µÄÉÌÒµºÍÀûÒæµÄÒþº¬
+ ±£Ö¤¡£
+ ÕâÀïÌṩµÄÕâ·ÝÈí¼þÊÇ»ùÓÚ¡°µ±×÷ÊÇ¡±µÄ»ù´¡µÄ£¬Òò¶ø¼ÓÖÝ´óѧûÓÐÔðÈÎÌṩά
+ »¤£¬Ö§³Ö£¬¸üУ¬ÔöÇ¿»òÕßÐ޸ĵķþÎñ¡£
+
+ £¨THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
+ INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
+ PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
+ CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
+ UPDATES, ENHANCEMENTS, OR MODIFICATIONS.£©
+
+ 1.3)PostgreSQL ¿ÉÒÔÔËÐÐÔÚÄÄЩ²Ù×÷ϵͳƽ̨ÉÏ£¿
+
+ Ò»°ã˵À´£¬Ò»¸öÏÖ´úµÄ UNIX ¼æÈݵÄƽ̨¶¼ÄÜÔËÐÐ PostgreSQL
+ ¡£ÔÚ°²×°Ö¸ÄÏÀïÁгöÁË·¢²¼Ê±¾¹ýÃ÷È·²âÊÔµÄƽ̨¡£
+
+ PostgreSQlÒ²¿ÉÒÔÖ±½ÓÔËÐÐÔÚ»ùÓÚ΢ÈíWindows-NTµÄ²Ù×÷ϵͳ£¬ÈçWin2000£¬Win
+ XP ºÍ Win2003£¬ÒÑÖÆ×÷Íê³ÉµÄ°²×°°ü¿É´Ó
+ http://pgfoundry.org/projects/pginstallerÏÂÔØ£¬»ùÓÚMSDOSµÄWindows²Ù×÷Ï
+ µÍ³ £¨Win95£¬Win98£¬WinMe£©ÐèҪͨ¹ýCygwinÄ£Äâ»·¾³ÔËÐÐPostgreSQL¡£
+
+ ͬʱҲÓÐÒ»¸öΪNovell Netware 6¿ª·¢µÄ°æ±¾¿É´Ó http://forge.novell.com
+ »ñÈ¡£¬ÎªOS/2¿ª·¢µÄ°æ±¾¿É´Ó
+ http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=postgre
+ SQL&stype=all&sort=type&dir=%2F
+
+ 1.4)ÎÒ´ÓÄÄÀïÄܵõ½ PostgreSQL£¿
+
+ ͨ¹ýä¯ÀÀÆ÷¿É´Óhttp://www.postgresql.org/ftp/ÏÂÔØ£¬Ò²¿Éͨ¹ýFTP£¬´Ó
+ ftp://ftp.PostgreSQL.org/pub/Õ¾µãÏÂÔØ¡£
+
+ 1.5)ÎÒ´ÓÄÄÀïÄܵõ½¶Ô PostgreSQL µÄÖ§³Ö£¿
+
+ PostgreSQLÉçÇøͨ¹ýÓʼþÁбíΪÆä´ó¶àÊýÓû§Ìṩ°ïÖú£¬¼ÓÈëÓʼþÁбíµÄÖ÷Õ¾µã
+ ÊÇ
+ http://www.postgresql.org/community/lists/£¬Ò»°ãÇé¿öÏ£¬ÏȼÓÈëGeneral
+ »ò BugÓʼþÁбíÊÇÒ»¸ö½ÏºÃµÄ¿ªÊ¼¡£
+
+ Ö÷ÒªµÄIRCƵµÀÊÇÔÚFreeNode(irc.freenode.net)µÄ#postgresql£¬ÎªÁËÁ¬ÉÏ´ËƵ
+ µÀ£¬¿ÉÒÔʹÓÃUNIX³ÌÐòirc£¬ÆäÖ¸Áî¸ñʽ£º irc -c '#postgresql' "$USER"
+ irc.freenode.net
+ £¬»òÕßʹÓÃÆäËûIRC¿Í»§¶Ë³ÌÐò¡£ÔÚ´ËÍøÂçÖл¹´æÔÚÒ»¸öPostgreSQLµÄÎ÷°àÑÀƵµ
+ À(#postgersql-es)ºÍ·¨ÓïƵµÀ
+ (#postgresql-fr)¡£Í¬ÑùµØ£¬ÔÚEFNETÉÏÒ²ÓÐÒ»¸öPostgreSQLµÄ½»Á÷ƵµÀ¡£
+
+ ÉÌÒµÖ§³Ö¹«Ë¾µÄÁбíÔÚ http://techdocs.postgresql.org/companies.php¡£
+
+ 1.6)ÎÒÈçºÎÌá½»Ò»¸öBUG±¨¸æ£¿
+
+ ¿É·ÃÎÊ
+ http://www.postgresql.org/support/submitbug£¬ÌîдBugÉϱ¨±í¸ñ¼´¿É¡£
+
+ ͬÑùÒ²¿É·ÃÎÊftpÕ¾µãftp://ftp.PostgreSQL.org/pub/
+ ¼ì²éÓÐÎÞ¸üеÄPostgreSQL°æ±¾»ò²¹¶¡¡£
+
+ 1.7)×îаæµÄPostgreSQL ÊÇʲô£¿
+
+ PostgreSQL ×îеİ汾ÊÇ°æ±¾ 8.0.2 £¨Òë×¢£ºÏÖ×îа汾Ϊ8.0.3£©¡£
+
+ ÎÒÃǼƻ®Ã¿Äê·¢²¼Ò»¸öÖ÷Òª°æ±¾£¬Ã¿¼¸¸öÔ·¢²¼Ò»¸öС°æ±¾¡£
+
+ 1.8)Äܹ»»ñÈ¡µÄ×îÐÂÎĵµÓÐÄÄЩ£¿
+
+ PostgreSQL°üº¬´óÁ¿µÄÎĵµ£¬Ö÷ÒªÓÐһЩÊֲᣬÊÖ²áÒ³ºÍһЩµÄ²âÊÔÀý×Ó¡£²Î¼û
+ /doc Ŀ¼£¨Òë×¢£ºÓ¦Îª $PGHOME/doc£©¡£ Ä㻹¿ÉÒÔÔÚÏßä¯ÀÀ PostgreSQL
+ µÄÊֲᣬÆäµØÖ·ÊÇ£ºhttp://www.PostgreSQL.org/docs¡£
+
+ ÓÐÁ½±¾¹ØÓÚ PostgreSQL µÄÊéÔÚÏßÌṩ£¬ÔÚ
+ http://www.PostgreSQL.org/docs/awbook.html ºÍ
+ http://www.commandprompt.com/ppbook/ ¡£
+ Ò²ÓдóÁ¿µÄPostgreSQLÊé¼®¿É¹©¹ºÂò£¬ÆäÖÐ×îΪÁ÷ÐеÄÒ»±¾ÊÇÓÉKorry
+ Douglas±àдµÄ¡£ÔÚ
+ http://techdocs.PostgreSQL.org/techdocs/bookreviews.phpÉÏ
+ ÉÏÓдóÁ¿ÓйØPostgreSQLÊé¼®µÄ¼ò½é¡£ ÔÚ
+ http://techdocs.PostgreSQL.org/ÉÏÊÕ¼¯ÁËÓÐ¹Ø PostgreSQL
+ µÄ´óÁ¿¼¼ÊõÎÄÕ¡£
+
+ ¿Í»§¶ËµÄÃüÁîÐгÌÐòpsqlÓÐһЩÒÔ \d
+ ¿ªÍ·µÄÃüÁ¿ÉÏÔʾ¹ØÓÚÀàÐÍ£¬²Ù×÷·û£¬º¯Êý£¬»ã×ܵȵÄÐÅÏ¢£¬Ê¹Óà \?
+ ¿ÉÒÔÏÔʾËùÓпÉÓõÄÃüÁî¡£
+
+ ÎÒÃÇµÄ web Õ¾µã°üº¬¸ü¶àµÄÎĵµ¡£
+
+ 1.9)ÎÒÈçºÎÁ˽âÒÑÖªµÄ BUG »òÔÝȱµÄ¹¦ÄÜ£¿
+
+ PostgreSQL Ö§³ÖÒ»¸öÀ©Õ¹Á赀 SQL-92 µÄ×Ó¼¯¡£²ÎÔÄÎÒÃǵÄTODO
+ ÁÐ±í£¬»ñÈ¡Ò»¸öÒÑÖªBug£¬ÔÝȱµÄ¹¦Äܺͽ«À´µÄ¼Æ»®¡£
+
+ 1.10)ÎÒÓ¦¸ÃÔõÑùѧϰ SQL £¿
+
+ Ê×ÏÈ¿¼ÂÇÉÏÊöÌáµ½µÄÓëPostgreSQLÏà¹ØµÄÊé¼®£¬ÁíÍâÒ»±¾ÊÇTeach Yourself SQL
+ in 21 Days, Second Edition£¬ ÎÒÃǵÄÐí¶àÓû§Ï²»¶The Practical SQL
+ Handbook Bowman, Judith S., et al., Addison-Wesley£¬ÆäËûµÄÔòϲ»¶ The
+ Complete Reference SQL, Groff et al., McGraw-Hill¡£
+
+ 1.11)ÎÒÓ¦¸ÃÔõÑù¼ÓÈ뿪·¢¶ÓÎ飿
+
+ Ïê¼û Developer's FAQ ¡£
+
+ 1.12)PostgreSQL ºÍÆäËûÊý¾Ý¿âϵͳ±ÈÆðÀ´ÈçºÎ£¿
+
+ ÆÀ¼ÛÈí¼þÓкü¸ÖÖ·½·¨£ºÌØÐÔ£¬ÐÔÄÜ£¬¿É¿¿ÐÔ£¬Ö§³ÖºÍ¼Û¸ñ¡£
+
+ ÌØÐÔ
+ PostgreSQL ÓµÓдóÐÍÉÌÓà DBMS Àï´ó¶àÊýÌØÐÔ£¬
+ ÀýÈ磺ÊÂÎñ£¬×Ó²éѯ£¬´¥·¢Æ÷£¬ÊÓͼ£¬Íâ¼ü²Î¿¼ÍêÕûÐԺ͸´ÔÓµÄËøµÈ¡£
+ ÎÒÃÇ»¹ÓÐһЩËüÃÇûÓеÄÌØÐÔ£¬ÈçÓû§¶¨ÒåÀàÐÍ£¬¼Ì³Ð£¬¹æÔòºÍ¶à°æ±¾²
+ ¢ÐпØÖÆÒÔ¼õÉÙËøµÄÕùÓõȡ£
+
+ ÐÔÄÜ
+ PostgreSQL ºÍÆäËûÉÌÓúͿªÔ´µÄÊý¾Ý¿â¾ßÓÐÀàËƵÄÐÔÄÜ¡£
+ ¶ÔijЩ´¦ÀíËü±È½Ï¿ì£¬¶ÔÆäËûһЩ´¦ÀíËü±È½ÏÂý¡£
+ ÓëÆäËûÊý¾Ý¿âÏà±È£¬ÎÒÃǵÄÐÔÄÜͨ³£ÔÚ +/- 10%Ö®¼ä¡£
+
+ ¿É¿¿ÐÔ
+ ÎÒÃÇÖªµÀ DBMS ±ØÐëÊÇ¿É¿¿µÄ£¬·ñÔòËü¾ÍÒ»µãÓö¼Ã»ÓС£
+ ÎÒÃÇŬÁ¦×öµ½·¢²¼¾
+ ¹ýÈÏÕæ²âÊԵģ¬Îȶ¨µÄ³ô³æ×îÉٵĴúÂ롣ÿ¸ö°æ±¾ÖÁÉÙÓÐÒ»¸öÔ嵀 beta
+ ²âÊÔʱ¼ä£¬²¢ÇÒÎÒÃǵķ¢²¼ÀúÊ·ÏÔʾÎÒÃÇ¿ÉÒÔÌṩÎȶ¨µÄ£¬Àι̵ģ¬¿ÉÓ
+ ÃÓÚÉú²úʹÓõİ汾¡£ÎÒÃÇÏàÐÅ
+ ÔÚÕâ·½ÃæÎÒÃÇÓëÆäËûµÄÊý¾Ý¿âÈí¼þÊÇÏ൱µÄ¡£
+
+ Ö§³Ö
+ ÎÒÃǵÄÓʼþÁбíÌṩһ¸ö·Ç³£´óµÄ¿ª·¢ÈËÔ±ºÍÓû§µÄ×éÒÔ°ïÖú½â¾öËùÅöµ
+ ½µÄÈκÎÎÊÌâ¡£ ÎÒÃDz»Äܱ£Ö¤¿Ï¶¨Äܽâ¾öÎÊÌ⣬Ïà±È֮ϣ¬ÉÌÓà DBMS
+ Ò²²¢²»ÊÇ×ÜÄܹ»Ìṩ½â¾ö·½·¨¡£
+ Ö±½ÓÓ뿪·¢ÈËÔ±£¬Óû§Èº£¬ÊÖ²áºÍÔ´³ÌÐò½Ó´¥Áî PostgreSQL
+ µÄÖ§³Ö±ÈÆäËû DBMS
+ »¹ÒªºÃ¡£»¹ÓÐһЩÉÌÒµÐÔµÄÔ¤°ü×°µÄÖ§³Ö£¬¿ÉÒÔ¸øÌṩ¸øÄÇЩÐèÒªµÄÈË¡
+ ££¨²ÎÔÄ FAQ Ìõ¿î 1.5 С½Ú£©
+
+ ¼Û¸ñ
+ ÎÒÃǶÔÈκÎÓÃ;¶¼Ãâ·Ñ£¬°üÀ¨ÉÌÓúͷÇÉÌÓÃÄ¿µÄ¡£
+ Äã¿ÉÒÔ²»¼ÓÏÞÖƵØÏòÄãµÄ²úÆ·Àï¼ÓÈëÎÒÃǵĴúÂ룬³ýÁËÄÇЩÎÒÃÇÔÚÉÏÃæµ
+ Ä°æȨÉùÃ÷ÀïÉùÃ÷µÄ BSD ·ç¸ñµÄ°æȨÍâ¡£
+
+ 1.13)Ë¿ØÖÆPostgreSQL £¿
+
+ Èç¹ûÄãÔÚÑ°ÕÒPostgreSQLµÄÕÆÃÅÈË£¬»òÊÇʲôÖÐÑëίԱ»á£¬»òÊÇʲôËùÊô¹«Ë¾£¬
+ ÄãÖ»ÄÜ·ÅÆúÁË---ÒòΪһ¸öÒ²²»´æÔÚ£¬µ«ÎÒÃǵÄÈ·ÓÐÒ»¸ö
+ ίԱ»áºÍCVS¹ÜÀí×飬µ«ÕâЩ¹¤×÷×éµÄÉèÁ¢Ö÷ÒªÊÇΪÁ˽øÐйÜÀí¹¤×÷¶ø²»ÊǶÔPos
+ tgreSQL½øÐпØÖÆ£¬PostgreSQLÏîÄ¿ÊÇÓÉÈκÎÈ˾ù
+ ¿É²Î¼ÓµÄ¿ª·¢ÈËÔ±ÉçÇøºÍËùÓÐÓû§¿ØÖƵģ¬ÄãËùÐèÒª×öµÄ¾ÍÊǼÓÈëÓʼþÁÐ±í£¬²Î
+ ÓëÌÖÂÛ¼´¿É£¨Òª²ÎÓëPostgreSQLµÄ¿ª·¢Ïê¼û Developer's FAQ »ñÈ¡ÐÅÏ¢£©¡£
+ _________________________________________________________________
+
+Óû§¿Í»§¶ËÎÊÌâ
+
+ 2.1)ÎÒÃÇ¿ÉÒÔÓÃʲôÓïÑÔºÍ PostgreSQL ´ò½»µÀ£¿
+
+ PostgreSQL(ȱʡÇé¿ö)Ö»°²×°ÓÐCºÍÄÚǶʽCµÄ½Ó¿Ú£¬ÆäËûµÄ½Ó¿Ú¶¼ÊǶÀÁ¢µÄÏîÄ¿
+ £¬Äܹ»·Ö±ðÏÂÔØ£¬ÕâЩ½Ó¿ÚÏîÄ¿¶ÀÁ¢µÄºÃ´¦
+ ÊÇËûÃÇ¿ÉÒÔÓи÷×Եķ¢²¼¼Æ»®ºÍ¸÷×Ô¶ÀÁ¢µÄ¿ª·¢×é¡£
+
+ һЩ±à³ÌÓïÑÔÈçPHP¶¼ÓзÃÎÊ PostgreSQL
+ µÄ½Ó¿Ú£¬Perl,TCL,PythonÒÔ¼°ºÜ¶àÆäËûÓïÑԵĽӿÚÔÚ
+ http://gborg.postgresql.org ÉϵÄDrivers/InterfacesС½Ú¿ÉÕÒµ½£¬
+ ²¢ÇÒͨ¹ýInternetºÜÈÝÒ×ËÑË÷µ½¡£
+
+ 2.2)ÓÐʲô¹¤¾ß¿ÉÒÔ°Ñ PostgreSQL ÓÃÓÚ Web Ò³Ã棿
+
+ Ò»¸ö½éÉÜÒÔÊý¾Ý¿âΪºǫ́µÄͦ²»´íµÄÕ¾µãÊÇ£ºhttp://www.webreview.com¡£
+
+ ¶ÔÓÚ Web ¼¯³É£¬PHP ÊÇÒ»¸ö¼«ºÃµÄ½Ó¿Ú¡£ËüÔÚ£ºhttp://www.php.net/¡£
+
+ ¶ÔÓÚ¸´ÔÓµÄÈÎÎñ£¬ºÜ¶àÈ˲ÉÓà Perl ½Ó¿ÚºÍ CGI.pm »ò mod_perl ¡£
+
+ 2.3)PostgreSQL ÓµÓÐͼÐÎÓû§½çÃæÂð£¿
+
+ Êǵģ¬ÔÚ
+ http://techdocs.postgresql.org/guides/GUIToolsÓÐÒ»¸öÏêϸµÄÁÐ±í¡£
+ _________________________________________________________________
+
+ϵͳ¹ÜÀíÎÊÌâ
+
+ 3.1)ÎÒÔõÑùÄÜ°Ñ PostgreSQL ×°ÔÚ /usr/local/pgsql ÒÔÍâµÄµØ·½£¿
+
+ ÔÚÔËÐÐ configure ʱ¼ÓÉÏ --prefix Ñ¡Ïî¡£
+
+ 3.2)ÎÒÈçºÎ¿ØÖÆÀ´×ÔÆäËûÖ÷»úµÄÁ¬½Ó£¿
+
+ ȱʡʱ£¬PostgreSQL Ö»ÔÊÐíͨ¹ý unix
+ ÓòÌ×½Ó×Ö»òTCP/IP·½Ê½ÇÒÀ´×Ô±¾»úµÄÁ¬½Ó¡£
+ ÄãÖ»ÓÐÔÚÐÞ¸ÄÁËÅäÖÃÎļþpostgresql.confÖеÄlisten_addresses£¬ÇÒÒ²ÔÚÅäÖÃÎ
+ ļþpg_hba.confÖдò¿ªÁË Ö÷»úΪ»ù´¡£¨ host-based
+ £©µÄÉí·ÝÈÏÖ¤£¬²¢ÖØÐÂÆô¶¯PostgreSQL£¬·ñÔòÆäËû»úÆ÷ÊDz»ÄÜÓëÄãµÄPostgreSQL
+ ·þÎñÆ÷Á¬½ÓµÄ¡£
+
+ 3.3)ÎÒÔõÑùµ÷ÕûÊý¾Ý¿âÒýÇæÒÔ»ñµÃ¸üºÃµÄÐÔÄÜ£¿
+
+ ÓÐÈý¸öÖ÷Òª·½Ãæ¿ÉÒÔÌáÉýPostgreSQLµÄDZÄÜ¡£
+
+ ²éѯ·½Ê½µÄ±ä»¯
+ ÕâÖ÷ÒªÉæ¼°Ð޸IJéѯ·½Ê½ÒÔ»ñÈ¡¸üºÃµÄÐÔÄÜ:
+
+ + ´´½¨Ë÷Òý£¬°üÀ¨±í´ïʽºÍ²¿·ÖË÷Òý£»
+ + ʹÓÃCOPYÓï¾ä´úÌæ¶à¸öInsertÓï¾ä£»
+ + ½«¶à¸öSQLÓï¾ä×é³ÉÒ»¸öÊÂÎñÒÔ¼õÉÙÌá½»ÊÂÎñµÄ¿ªÏú£»
+ + ´ÓÒ»¸öË÷ÒýÖÐÌáÈ¡¶àÌõ¼Ç¼ʱʹÓÃCLUSTER£»
+ + ´ÓÒ»¸ö²éѯ½á¹ûÖÐÈ¡³ö²¿·Ö¼Ç¼ʱʹÓÃLIMIT£»
+ + ʹÓÃÔ¤±àÒëʽ²éѯ£¨Prepared Query)£»
+ + ʹÓÃANALYZEÒÔ±£³Ö¾«È·µÄÓÅ»¯Í³¼Æ£»
+ + ¶¨ÆÚʹÓà VACUUM »ò pg_autovacuum
+ + ½øÐдóÁ¿Êý¾Ý¸ü¸ÄʱÏÈɾ³ýË÷Òý£¨È»ºóÖؽ¨Ë÷Òý£©
+
+ ·þÎñÆ÷µÄÅäÖÃ
+ ÅäÖÃÎļþpostgres.confÖеĺܶàÉèÖö¼»áÓ°ÏìÐÔÄÜ£¬ËùÓвÎÊýµÄÁбí¿É
+ ¼û£º Administration Guide/Server Run-time Environment/Run-time
+ Configuration£¬ ÓйزÎÊýµÄ½âÊͿɼû£º
+ http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_co
+ nf_e.html ºÍ
+ http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html¡£
+
+ Ó²¼þµÄÑ¡Ôñ
+ ¼ÆËã»úÓ²¼þ¶ÔÐÔÄܵÄÓ°Ïì¿Éä¯ÀÀ
+ http://candle.pha.pa.us/main/writings/pgsql/hw_performance/inde
+ x.html ºÍ http://www.powerpostgresql.com/PerfList/¡£
+
+ 3.4)PostgreSQL Àï¿ÉÒÔ»ñµÃʲôÑùµÄµ÷ÊÔÌØÐÔ£¿
+
+ PostgreSQL ÓкܶàÀàËÆ log_*
+ µÄ·þÎñÆ÷ÅäÖñäÁ¿¿ÉÓÃÓÚ²éѯµÄ´òÓ¡ºÍ½ø³Ìͳ¼Æ£¬¶øÕâЩ¹¤×÷¶Ôµ÷ÊÔºÍÐÔÄܲâÊÔ
+ ºÜÓаïÖú¡£
+
+ 3.5)ΪʲôÔÚÊÔͼÁ¬½ÓʱÊÕµ½¡°Sorry, too many clients¡±ÏûÏ¢£¿
+
+ Õâ±íʾÄãÒѴﵽȱʡ100¸ö²¢·¢ºǫ́½ø³ÌÊýµÄÏÞÖÆ£¬ÄãÐèҪͨ¹ýÐÞ¸Äpostgresql.
+ confÎļþÖеÄmax_connectionsÖµÀ´
+ Ôö¼ÓpostmasterµÄºǫ́²¢·¢´¦ÀíÊý£¬Ð޸ĺóÐèÖØÐÂÆô¶¯postmaster¡£
+
+ 3.6)ΪʲôҪÔÚÉý¼¶ PostgreSQL Ö÷Òª·¢²¼°æ±¾Ê±×ö dump ºÍ restore £¿
+
+ PostgreSQL ¿ª·¢×é¶Ôÿ´ÎСµÄÉý¼¶½ö×öÁ˽ÏÉÙµÄÐ޸ģ¬Òò´Ë´Ó 7.4.0 Éý¼¶µ½
+ 7.4.1 ²»ÐèÒª dump ºÍ restore¡£ µ«ÊÇÖ÷ÒªµÄÉý¼¶£¨ÀýÈç´Ó 7.3 µ½
+ 7.4£©Í¨³£»áÐÞ¸Äϵͳ±íºÍÊý¾Ý±íµÄÄÚ²¿¸ñʽ¡£
+ ÕâЩ±ä»¯Ò»°ã±È½Ï¸´ÔÓ£¬Òò´ËÎÒÃDz»Î¬Êý¾ÝÎļþµÄÏòºó¼æÈÝ¡£ dump
+ ½«Êý¾Ý°´ÕÕͨÓõĸñʽÊä³ö£¬Ëæºó¿ÉÒÔ±»ÖØмÓÔز¢Ê¹ÓÃеÄÄÚ²¿¸ñʽ¡£
+
+ 3.7)(ʹÓÃPostgreSQL)ÎÒÐèҪʹÓÃʲô¼ÆËã»úÓ²¼þ £¿
+
+ ÓÉÓÚ¼ÆËã»úÓ²¼þ´ó¶àÊýÊǼæÈݵģ¬ÈËÃÇ×ÜÊÇÇãÏòÓÚÏàÐÅËùÓмÆËã»úÓ²¼þÖÊÁ¿Ò²ÊÇ
+ ÏàͬµÄ¡£ÊÂʵÉϲ»ÊÇ£¬ ECC RAM£¨´øÆæżУÑéµÄÄڴ棩£¬SCSI
+ £¨Ó²ÅÌ£©ºÍÓÅÖʵÄÖ÷°å±ÈһЩ±ãÒË»õÒª¸ü¼Ó¿É¿¿ÇÒ¾ßÓиüºÃµÄÐÔÄÜ¡£PostgreSQL
+ ¼¸ºõ¿ÉÒÔÔËÐÐÔÚÈκÎÓ²¼þÉÏ£¬
+ µ«Èç¹û¿É¿¿ÐÔºÍÐÔÄܶÔÄãµÄϵͳºÜÖØÒª£¬Äã¾ÍÐèҪȫÃæµÄÑо¿Ò»ÏÂÄãµÄÓ²¼þÅäÖÃ
+ ÁË¡£ÔÚÎÒÃǵÄÓʼþÁбíÉÏÒ²ÓйØÓÚ Ó²¼þÅäÖúÍÐԼ۱ȵÄÌÖÂÛ¡£
+ _________________________________________________________________
+
+²Ù×÷ÎÊÌâ
+
+ 4.1)ÈçºÎֻѡÔñÒ»¸ö²éѯ½á¹ûµÄÍ·¼¸ÐУ¿»òÊÇËæ»úµÄÒ»ÐУ¿
+
+ Èç¹ûÄãÖ»ÊÇÒªÌáÈ¡¼¸ÐÐÊý¾Ý£¬²¢ÇÒÄãÔÚÖ´ÐвéѯÖÐÖªµÀÈ·ÇеÄÐÐÊý£¬Äã¿ÉÒÔʹÓÃ
+ LIMIT¹¦ÄÜ¡£ Èç¹ûÓÐÒ»¸öË÷ÒýÓë ORDER BYÖеÄÌõ¼þÆ¥Å䣬PostgreSQL
+ ¿ÉÄܾÍÖ»´¦ÀíÒªÇóµÄÍ·¼¸Ìõ¼Ç¼£¬
+ £¨·ñÔò½«¶ÔÕû¸ö²éѯ½øÐд¦ÀíÖ±µ½Éú³ÉÐèÒªµÄÐУ©¡£Èç¹ûÔÚÖ´Ðвéѯ¹¦ÄÜʱ²»Öª
+ µÀÈ·ÇеļǼÊý£¬ ¿ÉʹÓÃÓαê(cursor)ºÍFETCH¹¦ÄÜ¡£
+
+ ¿ÉʹÓÃÒÔÏ·½·¨ÌáÈ¡Ò»ÐÐËæ»ú¼Ç¼µÄ£º
+ SELECT cols
+ FROM tab
+ ORDER BY random()
+ LIMIT 1 ;
+
+ 4.2)ÈçºÎ²é¿´±í¡¢Ë÷Òý¡¢Êý¾Ý¿âÒÔ¼°Óû§µÄ¶¨Ò壿ÈçºÎ²é¿´psqlÀïÓõ½µÄ²éѯָÁî²¢Ï
+ ÔʾËüÃÇ£¿
+
+ ÔÚpsqlÖÐʹÓà \dt
+ ÃüÁîÀ´ÏÔʾÊý¾Ý±íµÄ¶¨Ò壬ҪÁ˽âpsqlÖеÄÍêÕûÃüÁîÁбí¿ÉʹÓÃ\?
+ £¬ÁíÍ⣬ÄãÒ²¿ÉÒÔÔĶÁ psql µÄÔ´´úÂë
+ Îļþpgsql/src/bin/psql/describe.c£¬Ëü°üÀ¨ÎªÉú³Épsql·´Ð±¸ÜÃüÁîµÄÊä³öµÄË
+ ùÓÐ SQL ÃüÁî¡£Ä㻹¿ÉÒÔ´ø -E Ñ¡ÏîÆô¶¯ psql£¬
+ ÕâÑùËü½«´òÓ¡³öÖ´ÐÐÄãÔÚpsqlÖÐËù¸ø³öµÄÃüÁîµÄÄÚ²¿Êµ¼ÊʹÓõÄSQL²éѯ¡£Postg
+ reSQLÒ²ÌṩÁËÒ»¸ö¼æÈÝSQLµÄINFORMATION SCHEMA½Ó¿Ú£¬
+ Äã¿ÉÒÔ´ÓÕâÀï»ñÈ¡¹ØÓÚÊý¾Ý¿âµÄÐÅÏ¢¡£
+
+ ÔÚϵͳÖÐÓÐһЩÒÔpg_ ´òÍ·µÄϵͳ±íÒ²ÃèÊöÁ˱íµÄ¶¨Òå¡£
+
+ ʹÓà psql -l Ö¸Áî¿ÉÒÔÁгöËùÓеÄÊý¾Ý¿â¡£
+
+ Ò²¿ÉÒÔä¯ÀÀÒ»ÏÂ
+ pgsql/src/tutorial/syscat.sourceÎļþ£¬ËüÁоÙÁ˺ܶà¿É´ÓÊý¾Ý¿âϵͳ±íÖлñ
+ È¡ÐÅÏ¢µÄSELECTÓï·¨¡£
+
+ 4.3)ÈçºÎ¸ü¸ÄÒ»¸ö×ֶεÄÊý¾ÝÀàÐÍ£¿
+
+ ÔÚ8.0°æ±¾Àï¸ü¸ÄÒ»¸ö×ֶεÄÊý¾ÝÀàÐͺÜÈÝÒ×£¬¿ÉʹÓà ALTER TABLE ALTER
+ COLUMN TYPE ¡£
+
+ ÔÚÒÔÇ°µÄ°æ±¾ÖУ¬¿ÉÒÔÕâÑù×ö£º
+ BEGIN;
+ ALTER TABLE tab ADD COLUMN new_col new_data_type;
+ UPDATE tab SET new_col = CAST(old_col AS new_data_type);
+ ALTER TABLE tab DROP COLUMN old_col;
+ COMMIT;
+
+ ÄãÈ»ºó¿ÉÒÔʹÓÃVACUUM FULL tab Ö¸ÁîÀ´Ê¹ÏµÍ³ÊÕ»ØÎÞЧÊý¾ÝËùÕ¼ÓõĿռ䡣
+
+ 4.4)Ò»ÐмǼ£¬Ò»¸ö±í£¬Ò»¸ö¿âµÄ×î´ó³ß´çÊǶàÉÙ£¿
+
+ ÏÂÃæÊÇһЩÏÞÖÆ£º
+
+ Ò»¸öÊý¾Ý¿â×î´ó³ß´ç£¿ ÎÞÏÞÖÆ£¨ÒÑ´æÔÚÓÐ 32TB µÄÊý¾Ý¿â£©
+ Ò»¸ö±íµÄ×î´ó³ß´ç£¿ 32 TB
+ Ò»ÐмǼµÄ×î´ó³ß´ç£¿ 1.6 TB
+ Ò»¸ö×ֶεÄ×î´ó³ß´ç? 1 GB
+ Ò»¸ö±íÀï×î´óÐÐÊý£¿ ÎÞÏÞÖÆ
+ Ò»¸ö±íÀï×î´óÁÐÊý£¿ 250-1600 £¨ÓëÁÐÀàÐÍÓйأ©
+ Ò»¸ö±íÀïµÄ×î´óË÷ÒýÊýÁ¿£¿ ÎÞÏÞÖÆ
+
+ µ±È»£¬Êµ¼ÊÉÏûÓÐÕæÕýµÄÎÞÏÞÖÆ£¬»¹ÊÇÒªÊÜ¿ÉÓôÅÅ̿ռ䡢¿ÉÓÃÄÚ´æ/½»»»ÇøµÄÖ
+ ÆÔ¼¡£ ÊÂʵÉÏ£¬µ±ÕâЩÊýÖµ±äµÃÒì³£µØ´óʱ£¬ÏµÍ³ÐÔÄÜÒ²»áÊܴܺóÓ°Ïì¡£
+
+ ±íµÄ×î´ó³ß´ç 32 TB ²»ÐèÒª²Ù×÷ϵͳ¶Ô´óÎļþµÄÖ§³Ö¡£´ó±íÓöà¸ö 1 GB
+ µÄÎļþ´æ´¢£¬Òò´ËÎļþϵͳ³ß´çµÄÏÞÖÆÊDz»ÖØÒªµÄ¡£
+
+ Èç¹ûȱʡµÄ¿é´óСÔö³¤µ½ 32K £¬×î´óµÄ±í³ß´çºÍ×î´óÁÐÊý»¹¿ÉÒÔÔö¼Óµ½Ëı¶¡£
+
+ 4.5)´æ´¢Ò»¸öµäÐ͵ÄÎı¾ÎļþÀïµÄÊý¾ÝÐèÒª¶àÉÙ´ÅÅ̿ռ䣿
+
+ Ò»¸ö Postgres
+ Êý¾Ý¿â£¨´æ´¢Ò»¸öÎı¾Îļþ£©ËùÕ¼ÓõĿռä×î¶à¿ÉÄÜÐèÒªÏ൱ÓÚÕâ¸öÎı¾Îļþ×Ô
+ Éí´óС5±¶µÄ´ÅÅ̿ռ䡣
+
+ ÀýÈ磬¼ÙÉèÓÐÒ»¸ö 100,000 ÐеÄÎļþ£¬Ã¿ÐÐÓÐÒ»¸öÕûÊýºÍÒ»¸öÎı¾ÃèÊö¡£
+ ¼ÙÉèÎı¾´®µÄƽ¾ù³¤¶ÈΪ20×Ö½Ú¡£Îı¾ÎļþÕ¼Óà 2.8 MB¡£´æ·ÅÕâЩÊý¾ÝµÄ
+ PostgreSQL Êý¾Ý¿âÎļþ´óÔ¼ÊÇ 6.4 MB:
+ 32 ×Ö½Ú: ÿÐеÄÍ·£¨¹À¼ÆÖµ£©
+ 24 ×Ö½Ú: Ò»¸öÕûÊýÐÍ×ֶκÍÒ»¸öÎı¾ÐÍ×Ö¶Î
+ + 4 ×Ö½Ú: Ò³ÃæÄÚÖ¸ÏòÔª×éµÄÖ¸Õë
+ ----------------------------------------
+ 60 ×Ö½ÚÿÐÐ
+
+ PostgreSQL Êý¾ÝÒ³µÄ´óСÊÇ 8192 ×Ö½Ú (8 KB)£¬Ôò£º
+
+ 8192 ×Ö½Úÿҳ
+ ------------------- = 136 ÐÐ/Êý¾ÝÒ³£¨ÏòÏÂÈ¡Õû£©
+ 60 ×Ö½ÚÿÐÐ
+
+ 100000 Êý¾ÝÐÐ
+ -------------------- = 735 Êý¾ÝÒ³£¨ÏòÉÏÈ¡Õû£©
+ 128 ÐÐÿҳ
+
+ 735 Êý¾ÝÒ³ * 8192 ×Ö½Ú/Ò³ = 6,021,120 ×Ö½Ú£¨6 MB£©
+
+ Ë÷Òý²»ÐèÒªÕâô¶àµÄ¶îÍâÏûºÄ£¬µ«Ò²È·Êµ°üÀ¨±»Ë÷ÒýµÄÊý¾Ý£¬Òò´ËËüÃÇÒ²¿ÉÄܺÜ
+ ´ó¡£
+
+ ¿ÕÖµNULL´æ·ÅÔÚλͼÖУ¬Òò´ËÕ¼ÓúÜÉٵĿռ䡣
+
+ 4.6)ΪʲôÎҵIJéѯºÜÂý£¿ÎªÊ²Ã´ÕâЩ²éѯûÓÐÀûÓÃË÷Òý£¿
+
+ ²¢·Çÿ¸ö²éѯ¶¼»á×Ô¶¯Ê¹ÓÃË÷Òý¡£Ö»ÓÐÔÚ±íµÄ´óС³¬¹ýÒ»¸ö×îСֵ£¬²¢ÇÒ²éѯֻ
+ »áÑ¡ÖбíÖнÏС±ÈÀýµÄ¼Ç¼ʱ²Å»á²ÉÓÃË÷Òý¡£
+ ÕâÊÇÒòΪË÷ÒýɨÃèÒýÆðµÄËæ¼´´ÅÅÌ´æÈ¡¿ÉÄܱÈÖ±½ÓµØ¶ÁÈ¡±í£¨Ë³ÐòɨÃ裩¸üÂý¡£
+
+ ΪÁËÅжÏÊÇ·ñʹÓÃË÷Òý£¬PostgreSQL±ØÐë»ñµÃÓйرíµÄͳ¼ÆÖµ¡£ÕâЩͳ¼ÆÖµ¿ÉÒÔ
+ ʹÓà VACUUM ANALYZE£¬»ò ANALYZE »ñµÃ¡£
+ ʹÓÃͳ¼ÆÖµ£¬ÓÅ»¯Æ÷ÖªµÀ±íÖÐÓжàÉÙÐУ¬¾ÍÄܹ»¸üºÃµØÅжÏÊÇ·ñÀûÓÃË÷Òý¡£
+ ͳ¼ÆÖµ¶ÔÈ·¶¨ÓÅ»¯µÄÁ¬½Ó˳ÐòºÍÁ¬½Ó·½·¨Ò²ºÜÓÐÓá£ÔÚ±íµÄÄÚÈÝ·¢Éú±ä»¯Ê±£¬Ó¦
+ ¶¨ÆÚ½øÐÐͳ¼ÆÖµµÄ¸üÐÂÊÕ¼¯¡£
+
+ Ë÷Òýͨ³£²»ÓÃÓÚ ORDER BY
+ »òÖ´ÐÐÁ¬½Ó¡£¶ÔÒ»¸ö´ó±íµÄÒ»´Î˳ÐòɨÃ裬ÔÙ×öÒ»¸öÏÔʽµÄÅÅÐòͨ³£±ÈË÷ÒýɨÃè
+ Òª¿ì¡£
+
+ µ«ÊÇ£¬ÔÚ LIMIT ºÍ ORDER BY ½áºÏʹÓÃʱ¾
+ ³£»áʹÓÃË÷Òý£¬ÒòΪÕâÖ»»á·µ»Ø±íµÄһС²¿·Ö¡£ ʵ¼ÊÉÏ£¬ËäÈ» MAX() ºÍ MIN()
+ ²¢²»Ê¹ÓÃË÷Òý£¬Í¨¹ý¶Ô ORDER BY ºÍ LLIMIT
+ ʹÓÃË÷ÒýÈ¡µÃ×î´óÖµºÍ×îСֵҲÊÇ¿ÉÒԵģº
+ SELECT col
+ FROM tab
+ ORDER BY col [ DESC ]
+ LIMIT 1;
+
+ Èç¹ûÄãÈ·ÐÅPostgreSQLµÄÓÅ»¯Æ÷ʹÓÃ˳ÐòɨÃèÊDz»ÕýÈ·µÄ£¬Äã¿ÉÒÔʹÓÃSET
+ enable_seqscan TO 'off'Ö¸Á
+ È»ºóÔÙ´ÎÔËÐвéѯ£¬Äã¾Í¿ÉÒÔ¿´³öʹÓÃÒ»¸öË÷ÒýɨÃèÊÇ·ñȷʵҪ¿ìһЩ¡£
+
+ µ±Ê¹ÓÃͨÅä·û²Ù×÷£¬ÀýÈç LIKE »ò ~ ʱ£¬Ë÷ÒýÖ»ÄÜÔÚÌض¨µÄÇé¿öÏÂʹÓãº
+ * ×Ö·û´®µÄ¿ªÊ¼²¿·Ö±ØÐëÊÇÆÕͨ×Ö·û´®£¬Ò²¾ÍÊÇ˵£º
+ + LIKE ģʽ²»ÄÜÒÔ % ´òÍ·¡£
+ + ~ £¨ÕýÔò±í´ïʽ£©Ä£Ê½±ØÐëÒÔ ^ ´òÍ·¡£
+ * ×Ö·û´®²»ÄÜÒÔÆ¥Åä¶à¸ö×Ö·ûµÄģʽÀà´òÍ·£¬ÀýÈç [a-e]¡£
+ * ´óСдÎ޹صIJéÕÒ£¬Èç ILIKE ºÍ ~* µÈ²»Ê¹ÓÃË÷Òý£¬µ«¿ÉÒÔÓà 4.8
+ ½ÚÃèÊöµÄº¯ÊýË÷Òý¡£
+ * ÔÚ×ö initdb ʱ±ØÐë²ÉÓÃȱʡµÄ±¾µØÉèÖà C
+ locale£¬ÒòΪϵͳ²»¿ÉÄÜÖªµÀÔÚ·ÇC localeÇé¿öʱÏÂÒ»¸ö×î´ó×Ö·ûÊÇʲô¡£
+ ÔÚÕâÖÖÇé¿öÏ£¬Äã¿ÉÒÔ´´½¨Ò»¸öÌØÊâµÄtext_pattern_opsË÷ÒýÀ´ÓÃÓÚLIKEµÄ
+ Ë÷Òý¡£
+
+ ÔÚ8.0֮ǰµÄ°æ±¾ÖУ¬³ý·ÇÒª²éѯµÄÊý¾ÝÀàÐͺÍË÷ÒýµÄÊý¾ÝÀàÐÍÏàÆ¥Å䣬·ñÔòË÷Ò
+ ý¾³£ÊÇδ±»Óõ½£¬ÌرðÊǶÔint2,int8ºÍÊýÖµÐ͵ÄË÷Òý¡£
+
+ 4.7)ÎÒÈçºÎ²ÅÄÜ¿´µ½²éѯÓÅ»¯Æ÷ÊÇÔõÑùÆÀ¹À´¦ÀíÎҵIJéѯ£¿
+
+ ²Î¿¼ EXPLAIN ÊÖ²áÒ³¡£
+
+ 4.8)ÎÒÔõÑù×öÕýÔò±í´ïʽËÑË÷ºÍ´óСдÎ޹صÄÕýÔò±í´ïʽ²éÕÒ£¿ÔõÑùÀûÓÃË÷Òý½øÐдóÐ
+ ¡Ð´Î޹زéÕÒ£¿
+
+ ²Ù×÷·û ~ ´¦ÀíÕýÔò±í´ïʽƥÅ䣬¶ø ~*
+ ´¦Àí´óСдÎ޹صÄÕýÔò±í´ïʽƥÅä¡£´óдЩÎÞ¹ØµÄ LIKE ±äÖÖ³ÉΪ ILIKE¡£
+
+ ´óСдÎ޹صĵÈʽ±È½Ïͨ³£Ð´×ö£º
+ SELECT *
+ FROM tab
+ WHERE lower(col) = 'abc';
+
+ ÕâÑù½«²»»áʹÓñê×¼µÄË÷Òý¡£µ«ÊÇ¿ÉÒÔ´´½¨Ò»¸ö¿É±»ÀûÓõĺ¯ÊýË÷Òý:
+ CREATE INDEX tabindex ON tab (lower(col));
+
+ 4.9)ÔÚÒ»¸ö²éѯÀÎÒÔõÑù¼ì²âÒ»¸ö×Ö¶ÎÊÇ·ñΪ NULL
+ £¿ÎÒÈçºÎ²ÅÄÜ׼ȷÅÅÐò¶ø²»ÂÛij×Ö¶ÎÊÇ·ñº¬ NULL Öµ£¿
+
+ Óà IS NULL ºÍ IS NOT NULL ²âÊÔÕâ¸ö×ֶΣ¬¾ßÌå·½·¨ÈçÏ£º
+ SELECT *
+ FROM tab
+ WHERE col IS NULL;
+
+ ΪÁËÄܶԺ¬ NULL×Ö¶ÎÅÅÐò£¬¿ÉÔÚ ORDER BY Ìõ¼þÖÐʹÓà IS NULLºÍ IS NOT
+ NULL ÐÞÊηû£¬Ìõ¼þΪÕæ true ½«±ÈÌõ¼þΪ¼Ùfalse
+ ÅÅÔÚÇ°Ã棬ÏÂÃæµÄÀý×ӾͻὫº¬ NULL µÄ¼Ç¼ÅÅÔÚ½á¹ûµÄÉÏÃ沿·Ö£º
+ SELECT *
+ FROM tab
+ ORDER BY (col IS NOT NULL)
+
+ 4.10)¸÷ÖÖ×Ö·ûÀàÐÍÖ®¼äÓÐʲô²»Í¬£¿
+
+ ÀàÐÍ ÄÚ²¿Ãû³Æ ˵Ã÷
+ VARCHAR(n) varchar
+ Ö¸¶¨ÁË×î´ó³¤¶È£¬±ä³¤×Ö·û´®£¬²»×㶨Ò峤¶ÈµÄ²¿·Ö²»²¹Æë
+ CHAR(n) bpchar ¶¨³¤×Ö·û´®£¬Êµ¼ÊÊý¾Ý²»×㶨Ò峤¶Èʱ£¬ÒÔ¿Õ¸ñ²¹Æë
+ TEXT text ûÓÐÌرðµÄÉÏÏÞÏÞÖÆ£¨½öÊÜÐеÄ×î´ó³¤¶ÈÏÞÖÆ£©
+ BYTEA bytea ±ä³¤×Ö½ÚÐòÁУ¨Ê¹ÓÃNULLÒ²ÊÇÔÊÐíµÄ£©
+ "char" char Ò»¸ö×Ö·û
+
+ ÔÚϵͳ±íºÍÔÚһЩ´íÎóÐÅÏ¢ÀïÄ㽫¿´µ½ÄÚ²¿Ãû³Æ¡£
+
+ ÉÏÃæËùÁеÄÇ°ËÄÖÖÀàÐÍÊÇ"varlena"£¨±ä³¤£©ÀàÐÍ£¨Ò²¾ÍÊÇ˵£¬¿ªÍ·µÄËĸö×Ö½ÚÊ
+ dz¤¶È£¬ºóÃæ²ÅÊÇÊý¾Ý£©¡£ ÓÚÊÇʵ¼ÊÕ¼ÓõĿռä±ÈÉùÃ÷µÄ´óСҪ¶àһЩ¡£
+ È»¶øÕâЩÀàÐͶ¼¿ÉÒÔ±»Ñ¹Ëõ´æ´¢£¬Ò²¿ÉÒÔÓà TOAST
+ ÍÑ»ú´æ´¢£¬Òò´Ë´ÅÅÌ¿Õ¼äÒ²¿ÉÄܱÈÔ¤ÏëµÄÒªÉÙ¡£
+
+ VARCHAR(n) ÔÚ´æ´¢ÏÞÖÆÁË×î´ó³¤¶ÈµÄ±ä³¤×Ö·û´®ÊÇ×îºÃµÄ¡£ TEXT
+ ÊÊÓÃÓÚ´æ´¢×î´ó¿É´ï 1G×óÓÒµ«Î´¶¨ÒåÏÞÖƳ¤¶ÈµÄ×Ö·û´®¡£
+
+ CHAR(n) ×îÊʺÏÓÚ´æ´¢³¤¶ÈÏàͬµÄ×Ö·û´®¡£
+ CHAR(n)»á¸ù¾ÝËù¸ø¶¨µÄ×ֶ㤶ÈÒÔ¿Õ¸ñ²¹×㣨²»×ãµÄ×Ö¶ÎÄÚÈÝ£©£¬ ¶ø
+ VARCHAR(n) Ö»´æ´¢Ëù¸ø¶¨µÄÊý¾ÝÄÚÈÝ¡£ BYTEA
+ ÓÃÓÚ´æ´¢¶þ½øÖÆÊý¾Ý£¬ÓÈÆäÊÇ°üº¬ NULL
+ ×Ö½ÚµÄÖµ¡£ÕâЩÀàÐ;ßÓÐÏàËƵÄÐÔÄÜÌØÐÔ¡£
+
+ 4.11.1)ÎÒÔõÑù´´½¨Ò»¸öÐòÁкÅ/×Ô¶¯µÝÔöµÄ×ֶΣ¿
+
+ PostgreSQL Ö§³Ö SERIAL
+ Êý¾ÝÀàÐÍ¡£ËüÔÚ×Ö¶ÎÉÏ×Ô¶¯´´½¨Ò»¸öÐòÁкÍË÷Òý¡£ÀýÈ磺
+ CREATE TABLE person (
+ id SERIAL,
+ name TEXT
+ );
+
+ »á×Ô¶¯×ª»»Îª£º
+ CREATE SEQUENCE person_id_seq;
+ CREATE TABLE person (
+ id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
+ name TEXT
+ );
+
+ ²Î¿¼ create_sequence ÊÖ²áÒ³»ñÈ¡¹ØÓÚÐòÁеĸü¶àÐÅÏ¢¡£
+
+ 4.11.2)ÎÒÈçºÎ»ñµÃÒ»¸ö²åÈëµÄÐòÁкŵÄÖµ£¿
+
+ Ò»ÖÖ·½·¨ÊÇÔÚ²åÈë֮ǰÏÈÓú¯Êý nextval() ´ÓÐòÁжÔÏóÀï¼ìË÷³öÏÂÒ»¸ö SERIAL
+ Öµ£¬È»ºóÔÙÏÔʽ²åÈ롣ʹÓà 4.11.1 ÀïµÄÀý±í£¬¿ÉÓÃαÂëÕâÑùÃèÊö£º
+ new_id = execute("SELECT nextval('person_id_seq')");
+ execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
+
+ ÕâÑù»¹ÄÜÔÚÆäËû²éѯÖÐʹÓôæ·ÅÔÚ new_id ÀïµÄÐÂÖµ£¨ÀýÈ磬×÷Ϊ person
+ ±íµÄÍâ¼ü£©¡£ ×¢Òâ×Ô¶¯´´½¨µÄ SEQUENCE ¶ÔÏóµÄÃû³Æ½«»áÊÇ
+ <table>_<serialcolumn>_seq£¬ ÕâÀï table ºÍ serialcolumn
+ ·Ö±ðÊÇÄãµÄ±íµÄÃû³ÆºÍÄãµÄ SERIAL ×ֶεÄÃû³Æ¡£
+
+ ÀàËƵģ¬ÔÚ SERIAL ¶ÔÏóȱʡ²åÈëºóÄã¿ÉÒÔÓú¯Êý currval() ¼ìË÷¸Õ¸³ÖµµÄ
+ SERIAL Öµ£¬ÀýÈ磺
+ execute("INSERT INTO person (name) VALUES ('Blaise Pascal')");
+ new_id = execute("SELECT currval('person_id_seq')");
+
+ 4.11.3)ʹÓà currval() »áµ¼ÖºÍÆäËûÓû§µÄ³åÍ»Çé¿ö£¨race condition£©Âð£¿
+
+ ²»»á¡£currval() ·µ»ØµÄÊÇÄã±¾´Î»á»°½ø³ÌËù¸³µÄÖµ¶ø²»ÊÇËùÓÐÓû§µÄµ±Ç°Öµ¡£
+
+ 4.11.4)Ϊʲô²»ÔÚÊÂÎñÒì³£ÖÐÖ¹ºóÖØÓÃÐòÁкÅÄØ£¿ÎªÊ²Ã´ÔÚÐòÁкÅ×ֶεÄÈ¡ÖµÖдæÔÚ
+ ¼ä¶ÏÄØ£¿
+
+ ΪÁËÌá¸ß²¢·¢ÐÔ£¬ÐòÁкÅÔÚÐèÒªµÄʱºò¸³ÓèÕýÔÚÔËÐеÄÊÂÎñ£¬²¢ÇÒÔÚÊÂÎñ½áÊøÖ®
+ Ç°²»½øÐÐËø¶¨£¬ Õâ¾Í»áµ¼ÖÂÒì³£ÖÐÖ¹µÄÊÂÎñºó£¬ÐòÁкŻá³öÏÖ¼ä¸ô¡£
+
+ 4.12)ʲôÊÇ OID £¿Ê²Ã´ÊÇ CTID £¿
+
+ PostgreSQL
+ Àï´´½¨µÄÿһÐмǼ¶¼»á»ñµÃÒ»¸öΨһµÄOID£¬³ý·ÇÔÚ´´½¨±íʱʹÓÃWITHOUT
+ OIDSÑ¡Ïî¡£ OID´´½¨Ê±»á×Ô¶¯Éú³ÉÒ»¸ö4×Ö½ÚµÄÕûÊý£¬ËùÓÐ OID ÔÚÕû¸ö
+ PostgreSQL ÖоùÊÇΨһµÄ¡£ È»¶ø£¬ËüÔÚ³¬¹ý40ÒÚʱ½«Òç³ö£¬
+ OID´Ëºó»á³öÏÖÖظ´¡£PostgreSQL ÔÚËüµÄÄÚ²¿ÏµÍ³±íÀïʹÓà OID
+ ÔÚ±íÖ®¼ä½¨Á¢ÁªÏµ¡£
+
+ ÔÚÓû§µÄÊý¾Ý±íÖУ¬×îºÃÊÇʹÓÃSERIAlÀ´´úÌæOID
+ ÒòΪSERIALÖ»ÊDZ£Ö¤ÔÚµ¥¸ö±íÖÐÊý¾ÝÊÇΨһµÄ£¬ÕâÑùËüÒç³öµÄ¿ÉÄÜÐԾͷdz£Ð¡ÁË
+ £¬ SERIAL8¿ÉÓÃÀ´±£´æ8×Ö½ÚµÄÐòÁкÅ×ֶΡ£
+
+ CTID ÓÃÓÚ±êʶ´ø×ÅÊý¾Ý¿é£¨µØÖ·£©ºÍ£¨¿éÄÚ£©Æ«ÒƵÄÌض¨µÄÎïÀíÐС£ CTID
+ ÔڼǼ±»¸ü¸Ä»òÖØÔغó·¢Éú¸Ä±ä¡£Ë÷ÒýÈë¿ÚʹÓÃËüÃÇÖ¸ÏòÎïÀíÐС£
+
+ 4.13)ΪʲôÎÒÊÕµ½´íÎóÐÅÏ¢¡°ERROR: Memory exhausted in AllocSetAlloc()¡±£¿
+
+ ÕâºÜ¿ÉÄÜÊÇϵͳµÄÐéÄâÄÚ´æÓùâÁË£¬»òÕßÄں˶ÔijЩ×ÊÔ´Óнϵ͵ÄÏÞÖÆÖµ¡£ÔÚÆô
+ ¶¯ postmaster ֮ǰÊÔÊÔÏÂÃæµÄÃüÁ
+ ulimit -d 262144
+ limit datasize 256m
+
+ È¡¾öÓÚÄãÓõÄ
+ shell£¬ÉÏÃæÃüÁîÖ»ÓÐÒ»ÌõÄܳɹ¦£¬µ«ÊÇËü½«°ÑÄãµÄ½ø³ÌÊý¾Ý¶ÎÏÞÖÆÉèµÃ±È½Ï¸ß£
+ ¬
+ Òò¶øÒ²ÐíÄÜÈòéѯÍê³É¡£ÕâÌõÃüÁîÓ¦ÓÃÓÚµ±Ç°½ø³Ì£¬ÒÔ¼°ËùÓÐÔÚÕâÌõÃüÁîÔËÐкó
+ ´´½¨µÄ×Ó½ø³Ì¡£
+ Èç¹ûÄãÊÇÔÚÔËÐÐSQL¿Í»§¶ËʱÒòΪºǫ́·µ»ØÁËÌ«¶àµÄÊý¾Ý¶ø³öÏÖÎÊÌ⣬ÇëÔÚÔËÐп
+ Í»§¶Ë֮ǰִÐÐÉÏÊöÃüÁî¡£
+
+ 4.14)ÎÒÈçºÎ²ÅÄÜÖªµÀËùÔËÐÐµÄ PostgreSQL µÄ°æ±¾£¿
+
+ ´Ó psql ÀÊäÈë SELECT version();Ö¸Áî¡£
+
+ 4.15)ÎÒÈçºÎ´´½¨Ò»¸öȱʡֵÊǵ±Ç°Ê±¼äµÄ×ֶΣ¿
+
+ ʹÓà CURRENT_TIMESTAMP£º
+ CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
+
+ 4.16)ÎÒÔõÑù½øÐÐ outer join £¨ÍâÁ¬½Ó£©£¿
+
+ PostgreSQL ²ÉÓñê×¼µÄ SQL Óï·¨Ö§³ÖÍâÁ¬½Ó¡£ÕâÀïÊÇÁ½¸öÀý×Ó£º
+ SELECT *
+ FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
+
+ »òÊÇ
+ SELECT *
+ FROM t1 LEFT OUTER JOIN t2 USING (col);
+
+ ÕâÁ½¸öµÈ¼ÛµÄ²éѯÔÚ t1.col ºÍ t2.col ÉÏ×öÁ¬½Ó£¬²¢ÇÒ·µ»Ø t1
+ ÖÐËùÓÐδÁ¬½ÓµÄÐУ¨ÄÇЩÔÚ t2 ÖÐûÓÐÆ¥ÅäµÄÐУ©¡£ ÓÒ[Íâ]Á¬½Ó(RIGHT OUTER
+ JOIN)½«·µ»Ø t2 ÖÐδÁ¬½ÓµÄÐС£ ÍêÈ«ÍâÁ¬½Ó£¨FULL OUTER JOIN£©½«·µ»Ø t1
+ ºÍ t2 ÖÐδÁ¬½ÓµÄÐС£ ¹Ø¼ü×Ö OUTER
+ ÔÚ×ó[Íâ]Á¬½Ó¡¢ÓÒ[Íâ]Á¬½ÓºÍÍêÈ«[Íâ]Á¬½ÓÖÐÊÇ¿ÉÑ¡µÄ£¬ÆÕͨÁ¬½Ó±»³ÆΪÄÚÁ¬½Ó
+ £¨INNER JOIN£©¡£
+
+ 4.17)ÈçºÎʹÓÃÉæ¼°¶à¸öÊý¾Ý¿âµÄ²éѯ£¿
+
+ ûÓа취²éѯµ±Ç°Êý¾Ý¿âÖ®ÍâµÄÊý¾Ý¿â¡£ ÒòΪ PostgreSQL
+ Òª¼ÓÔØÓëÊý¾Ý¿âÏà¹ØµÄϵͳĿ¼£¨ÏµÍ³±í£©£¬Òò´Ë¿çÊý¾Ý¿âµÄ²éѯÈçºÎÖ´ÐÐÊDz»
+ ¶¨µÄ¡£
+
+ ¸½¼ÓÔöֵģ¿écontrib/dblinkÔÊÐí²ÉÓú¯Êýµ÷ÓÃʵÏÖ¿ç¿â²éѯ¡£µ±È»Óû§Ò²¿ÉÒÔ
+ ͬʱÁ¬½Óµ½²»Í¬µÄÊý¾Ý¿âÖ´ÐвéѯȻºóÔÚ¿Í»§¶ËºÏ²¢½á¹û¡£
+
+ 4.18)ÈçºÎÈú¯Êý·µ»Ø¶àÐлò¶àÁУ¿
+
+ ÔÚº¯ÊýÖзµ»ØÊý¾Ý¼Ç¼¼¯µÄ¹¦ÄÜÊǺÜÈÝÒ×ʹÓõģ¬ÏêÇé²Î¼û£º
+ http://techdocs.postgresql.org/guides/SetReturningFunctions
+
+ 4.19)ΪʲôÎÒÔÚʹÓÃPL/PgSQLº¯Êý´æÈ¡ÁÙʱ±íʱ»áÊÕµ½´íÎóÐÅÏ¢¡°relation with
+ OID ##### does not exist¡±£¿
+
+ PL/PgSQL»á»º´æº¯ÊýµÄÄÚÈÝ£¬ÓÉ´Ë´øÀ´µÄÒ»¸ö²»ºÃµÄ¸±×÷ÓÃÊÇÈôÒ»¸ö PL/PgSQL
+ º¯Êý·ÃÎÊÁËÒ»¸öÁÙʱ±í£¬È»ºó¸Ã±í±»É¾³ý²¢Öؽ¨ÁË£¬ÔòÔٴε÷Óøú¯Êý½«Ê§°Ü£¬
+ ÒòΪ»º´æµÄº¯ÊýÄÚÈÝÈÔȻָÏò¾ÉµÄÁÙʱ±í¡£½â¾öµÄ·½·¨ÊÇÔÚ PL/PgSQL
+ ÖÐÓÃEXECUTE ¶ÔÁÙʱ±í½øÐзÃÎÊ¡£ÕâÑù»á±£Ö¤²éѯÔÚÖ´ÐÐÇ°×ܻᱻÖØнâÎö¡£
+
+ 4.27)Ä¿Ç°ÓÐÄÄЩÊý¾Ý¸´ÖÆ·½°¸¿ÉÓã¿
+
+ ¡°¸´ÖÆ¡±Ö»ÊÇÒ»¸öÊõÓÓкü¸ÖÖ¸´ÖƼ¼Êõ¿ÉʹÓã¬Ã¿ÖÖ¶¼ÓÐÓŵãºÍȱµã£º
+
+ Ö÷/´Ó¸´ÖÆ·½Ê½ÊÇÔÊÐíÒ»¸öÖ÷·þÎñÆ÷½ÓÊܶÁ/дµÄÉêÇ룬¶ø¶à¸ö´Ó·þÎñÆ÷Ö»ÄܽÓÊÜ
+ ¶Á/SELECT²éѯµÄÉêÇ룬 Ä¿Ç°×îÁ÷ÐÐÇÒÊÇÃâ·ÑµÄÖ÷/´Ó PostgreSQL¸´ÖÆ·½°¸ÊÇ
+ Slony-I ¡£
+
+ ¶à¸öÖ÷·þÎñÆ÷µÄ¸´ÖÆ·½Ê½ÔÊÐí½«¶Á/дµÄÉêÇë·¢Ë͸ø¶ą̀µÄ¼ÆËã»ú£¬ÕâÖÖ·½Ê½ÓÉÓ
+ ÚÐèÒªÔÚ¶ą̀·þÎñÆ÷Ö®¼äͬ²½Êý¾Ý±ä¶¯
+ ¿ÉÄÜ»á´øÀ´½ÏÑÏÖصÄÐÔÄÜËðʧ£¬PgclusterÊÇÄ¿Ç°ÕâÖÖ·½°¸
+ ÖÐ×îºÃµÄ£¬¶øÇÒ»¹¿ÉÒÔÃâ·ÑÏÂÔØ¡£
+
+ Ò²ÓÐһЩÉÌÒµÐ踶·ÑºÍ»ùÓÚÓ²¼þµÄÊý¾Ý¸´ÖÆ·½°¸£¬Ö§³ÖÉÏÊö¸÷ÖÖ¸´ÖÆÄ£ÐÍ¡£
--- /dev/null
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i6LENoq23921
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id C3BE2D1B2D9
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 59019-03
+ Wed, 21 Jul 2004 14:22:42 +0000 (GMT)
+Received: from www.roaringpenguin.com (www.roaringpenguin.com [206.191.13.82])
+ by svr1.postgresql.org (Postfix) with ESMTP id 0F71DD1B179
+Received: from ottawa-hs-209-217-122-117.s-ip.magma.ca (ottawa-hs-209-217-122-117.s-ip.magma.ca [209.217.122.117])
+ by www.roaringpenguin.com (8.13.0/8.13.0) with ESMTP id i6LEMP8J001515;
+ Wed, 21 Jul 2004 10:22:25 -0400
+Received: from shishi.roaringpenguin.com (shishi.roaringpenguin.com [192.168.2.3])
+ by shevy.roaringpenguin.com (8.12.10/8.12.10) with ESMTP id i6LEMPCl015669;
+ Wed, 21 Jul 2004 10:22:25 -0400
+Date: Wed, 21 Jul 2004 10:22:25 -0400 (EDT)
+Subject: Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-patches
+Precedence: bulk
+X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
+ candle.pha.pa.us
+X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no
+ version=2.61
+Status: OR
+
+On Wed, 21 Jul 2004, Bruce Momjian wrote:
+
+> Even though I suggested it, I am afraid this is just too confusing an API.
+
+How about this:
+
+pg_dump -t t1 -- Dump table t1 in any schema
+pg_dump -n s1 -- Dump all of schema s1
+pg_dump -t t1 -n s1 -- Dump t1 in s1
+pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2
+pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2
+
+Basically, no "-t" option means dump all tables. No "-n" option
+means dump all schemas. If any "-t" or "-n" options are present,
+then we only dump the specified tables/schemas. We also probably
+should not warn about missing tables, because it's likely that the
+full cartesian product of schemas and tables won't exist.
+
+And we nuke the -T and -N options.
+
+Regards,
+
+David.
+
+---------------------------(end of broadcast)---------------------------
+TIP 3: if posting/reading through Usenet, please send an appropriate
+ message can get through to the mailing list cleanly
+
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i6LF11q28864
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id DAF37D1B38A
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 83756-03
+ Wed, 21 Jul 2004 14:59:51 +0000 (GMT)
+Received: from www.roaringpenguin.com (www.roaringpenguin.com [206.191.13.82])
+ by svr1.postgresql.org (Postfix) with ESMTP id AD03CD1B392
+Received: from ottawa-hs-209-217-122-117.s-ip.magma.ca (ottawa-hs-209-217-122-117.s-ip.magma.ca [209.217.122.117])
+ by www.roaringpenguin.com (8.13.0/8.13.0) with ESMTP id i6LExYLg004261;
+ Wed, 21 Jul 2004 10:59:39 -0400
+Received: from shishi.roaringpenguin.com (shishi.roaringpenguin.com [192.168.2.3])
+ by shevy.roaringpenguin.com (8.12.10/8.12.10) with ESMTP id i6LExSCl015967;
+ Wed, 21 Jul 2004 10:59:28 -0400
+Date: Wed, 21 Jul 2004 10:59:28 -0400 (EDT)
+Subject: Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-patches
+Precedence: bulk
+X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
+ candle.pha.pa.us
+X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no
+ version=2.61
+Status: OR
+
+On Wed, 21 Jul 2004, Tom Lane wrote:
+
+> pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
+
+That's a good idea, but then it's questionable whether we need the -n
+switch at all. It might be simpler to extend the -t switch to
+accept:
+
+ pg-dump -t 's1.*'
+
+rather than using a -n switch. Of course, that breaks
+backward-compatibility.
+
+Regards,
+
+David.
+
+---------------------------(end of broadcast)---------------------------
+TIP 8: explain analyze is your friend
+
+Received: from www.roaringpenguin.com (www.roaringpenguin.com [206.191.13.82])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i6LExkq28467
+Received: from ottawa-hs-209-217-122-117.s-ip.magma.ca (ottawa-hs-209-217-122-117.s-ip.magma.ca [209.217.122.117])
+ by www.roaringpenguin.com (8.13.0/8.13.0) with ESMTP id i6LExYLg004261;
+ Wed, 21 Jul 2004 10:59:39 -0400
+Received: from shishi.roaringpenguin.com (shishi.roaringpenguin.com [192.168.2.3])
+ by shevy.roaringpenguin.com (8.12.10/8.12.10) with ESMTP id i6LExSCl015967;
+ Wed, 21 Jul 2004 10:59:28 -0400
+Date: Wed, 21 Jul 2004 10:59:28 -0400 (EDT)
+Subject: Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T
+ option
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
+ candle.pha.pa.us
+X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
+ version=2.61
+Status: OR
+
+On Wed, 21 Jul 2004, Tom Lane wrote:
+
+> pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
+
+That's a good idea, but then it's questionable whether we need the -n
+switch at all. It might be simpler to extend the -t switch to
+accept:
+
+ pg-dump -t 's1.*'
+
+rather than using a -n switch. Of course, that breaks
+backward-compatibility.
+
+Regards,
+
+David.
+
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i6LFBEq00216
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id A9242D1B269
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 89636-05
+ Wed, 21 Jul 2004 15:09:23 +0000 (GMT)
+Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
+ by svr1.postgresql.org (Postfix) with ESMTP id 73F3CD1B398
+Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
+ by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i6LF9H0c008840;
+ Wed, 21 Jul 2004 11:09:17 -0400 (EDT)
+Subject: Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T option
+ message dated "Wed, 21 Jul 2004 10:59:28 -0400"
+Date: Wed, 21 Jul 2004 11:09:17 -0400
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-patches
+Precedence: bulk
+X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
+ candle.pha.pa.us
+X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no
+ version=2.61
+Status: ORr
+
+> On Wed, 21 Jul 2004, Tom Lane wrote:
+>> pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2
+
+> That's a good idea, but then it's questionable whether we need the -n
+> switch at all.
+
+Sure we do --- for backwards compatibility if nothing else.
+
+> It might be simpler to extend the -t switch to accept:
+> pg-dump -t 's1.*'
+
+That would not be the same thing --- that would mean to dump *only tables*
+from s1, rather than objects of all types. Anyway, I think it's a bit
+late in this cycle to be proposing to implement wild-card matching.
+Maybe for next time someone can do that, but for 7.5 I think we should
+limit ourselves to cleaning up any design flaws of the already-submitted
+patch.
+
+ regards, tom lane
+
+---------------------------(end of broadcast)---------------------------
+TIP 7: don't forget to increase your free space map settings
+
+Received: from inetserver.servicepaper.com (67.105.202.226.ptr.us.xo.net [67.105.202.226])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i7I1FYN06577
+Received: from glen ([192.168.10.100])
+ by inetserver.servicepaper.com (8.11.6/8.11.6) with SMTP id i7I1FPP01863
+Subject: RE: [GENERAL] pg_dump feature request: Exclude tables?
+Date: Tue, 17 Aug 2004 18:16:27 -0700
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset="us-ascii"
+Content-Transfer-Encoding: 7bit
+X-Priority: 3 (Normal)
+X-MSMail-Priority: Normal
+X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
+X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
+Importance: Normal
+X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
+ candle.pha.pa.us
+X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
+ version=2.61
+Status: OR
+
+> No, we have:
+>
+> * Allow pg_dump to use multiple -t and -n switches
+>
+> This should be done by allowing a '-t schema.table' syntax.
+>
+> but that doesn't have the exclude option. We had a patch that
+> implemented an exclude but got confused over how it would interact with
+> the schema switch and stuff. However, with the new '-t schema.table'
+> syntax we might be able to get it working.
+
+Hmm, while you're at it, maybe you could make it accept wild cards or regexp
+or something :-) That should allow you to toss the -n parameter altogether
+(schema.*) if you wanted to.
+
+It would also be at least as good, IMO, to accept only one -t option,
+re-defined as a comma-seperated list of names... And an exlusion parameter
+defined the same way.
+
+Glen Parker
+
+Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i7I1KuN08623
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id B02F15E40BB
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ Wed, 18 Aug 2004 01:20:47 +0000 (GMT)
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by svr1.postgresql.org (Postfix) with ESMTP id 5D09C5E40BA
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id A33B15E3F15
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 32509-09
+ Wed, 18 Aug 2004 01:14:56 +0000 (GMT)
+Received: from seahorse.shentel.net (seahorse.shentel.net [204.111.11.44])
+ by svr1.postgresql.org (Postfix) with ESMTP id 404585E37CE
+Received: from [204.111.24.205] (ha24s205.d.shentel.net [204.111.24.205])
+ by seahorse.shentel.net (8.12.11/8.12.11) with ESMTP id i7I1EwKM023339
+Date: Tue, 17 Aug 2004 21:23:56 -0400
+User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
+X-Accept-Language: en-us, en
+MIME-Version: 1.0
+Subject: Re: [GENERAL] pg_dump feature request: Exclude tables?
+Content-Type: text/plain; charset=iso-8859-1; format=flowed
+Content-Transfer-Encoding: 7bit
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-general
+Precedence: bulk
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
+ candle.pha.pa.us
+X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE
+ autolearn=ham version=2.61
+Status: OR
+
+I second this. I would prefer an option to dump only the schema of
+certain tables rather than excluding them altogether.
+
+Paul
+
+
+Glen Parker wrote:
+
+>Since pg_dump will be allowing multiple -t <table> parameters for 8.0, here
+>is a related feature request.
+>
+>A similar option (allowing multiples also) to EXCLUDE tables, so we can do a
+>dump of the entire database minus a few tables.
+>
+>Glen Parker
+>
+>
+>---------------------------(end of broadcast)---------------------------
+>TIP 7: don't forget to increase your free space map settings
+>
+>
+>
+>
+
+
+---------------------------(end of broadcast)---------------------------
+TIP 8: explain analyze is your friend
+
+Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i7IGI8N29982
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id AB9565E46C1;
+ Wed, 18 Aug 2004 13:17:56 -0300 (ADT)
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 43866-08; Wed, 18 Aug 2004 16:18:04 +0000 (GMT)
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by svr1.postgresql.org (Postfix) with ESMTP id 5E6C65E46BF;
+ Wed, 18 Aug 2004 13:17:56 -0300 (ADT)
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id BD6215E46DF
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 42880-02
+ Wed, 18 Aug 2004 16:11:24 +0000 (GMT)
+Received: from mail.travelamericas.com (unknown [206.130.134.147])
+ by svr1.postgresql.org (Postfix) with SMTP id E4A055E46D5
+Received: (qmail 30270 invoked from network); 18 Aug 2004 16:11:20 -0000
+Received: from unknown (HELO ?10.0.0.128?) (10.0.0.128)
+ by verkiel.travelamericas.com with SMTP; 18 Aug 2004 16:11:20 -0000
+Date: Wed, 18 Aug 2004 09:11:19 -0700
+User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
+X-Accept-Language: en-us, en
+MIME-Version: 1.0
+Subject: Re: [GENERAL] pg_dump feature request: Exclude tables?
+Content-Type: text/plain; charset=us-ascii; format=flowed
+Content-Transfer-Encoding: 7bit
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-general
+Precedence: bulk
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
+ candle.pha.pa.us
+X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
+ version=2.61
+Status: OR
+
+Glen Parker wrote:
+
+>>No, we have:
+>>
+>> * Allow pg_dump to use multiple -t and -n switches
+>>
+>> This should be done by allowing a '-t schema.table' syntax.
+>>
+>>but that doesn't have the exclude option. We had a patch that
+>>implemented an exclude but got confused over how it would interact with
+>>the schema switch and stuff. However, with the new '-t schema.table'
+>>syntax we might be able to get it working.
+>>
+>>
+>
+>Hmm, while you're at it, maybe you could make it accept wild
+>cards or regexp or something :-) That should allow you to toss
+>the -n parameter altogether (schema.*) if you wanted to.
+>
+>It would also be at least as good, IMO, to accept only one -t
+>option, re-defined as a comma-seperated list of names... And an
+>exlusion parameter defined the same way.
+>
+>
+>
+How would this interact with the shell? It seems like a supportability
+issue if we have to require single quotes around such arguments.
+
+Best Wishes,
+Chris Travers
+Metatron Technology Consulting
+
+
+---------------------------(end of broadcast)---------------------------
+TIP 2: you can get off all lists at once with the unregister command
+
+Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i7IJHcN23505
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id AE56A5E46FB;
+ Wed, 18 Aug 2004 16:17:24 -0300 (ADT)
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 16779-02; Wed, 18 Aug 2004 19:17:32 +0000 (GMT)
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by svr1.postgresql.org (Postfix) with ESMTP id 664675E46FA;
+ Wed, 18 Aug 2004 16:17:24 -0300 (ADT)
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 8DD235E46DC
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 13875-03
+ Wed, 18 Aug 2004 19:10:30 +0000 (GMT)
+Received: from inetserver.servicepaper.com (67.105.202.226.ptr.us.xo.net [67.105.202.226])
+ by svr1.postgresql.org (Postfix) with ESMTP id 78ED55E46D4
+Received: from glen ([192.168.10.100])
+ by inetserver.servicepaper.com (8.11.6/8.11.6) with SMTP id i7IJAPP13962
+Subject: Re: [GENERAL] pg_dump feature request: Exclude tables?
+Date: Wed, 18 Aug 2004 12:11:03 -0700
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset="us-ascii"
+Content-Transfer-Encoding: 7bit
+X-Priority: 3 (Normal)
+X-MSMail-Priority: Normal
+X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
+X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
+Importance: Normal
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-general
+Precedence: bulk
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
+ candle.pha.pa.us
+X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
+ version=2.61
+Status: OR
+
+> >Hmm, while you're at it, maybe you could make it accept wild
+> >cards or regexp or something :-) That should allow you to toss
+> >the -n parameter altogether (schema.*) if you wanted to.
+> >
+> >It would also be at least as good, IMO, to accept only one -t
+> >option, re-defined as a comma-seperated list of names... And an
+> >exlusion parameter defined the same way.
+> >
+> How would this interact with the shell? It seems like a supportability
+> issue if we have to require single quotes around such arguments.
+
+I think wild cards would be extremely useful, but you're right, it can't be
+required for common cases. Maybe "-t schema." could be shorthand for "-t
+schema.*".
+
+As far as the comma-seperated-list notion, I could take it or leave it. But
+it absolutely does not require quoting unless you add superfluous
+whitespace. That's just common, basic shell usage.
+
+Glen Parker
+
+
+---------------------------(end of broadcast)---------------------------
+TIP 6: Have you searched our list archives?
+
+ http://archives.postgresql.org
+
+Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i7JAApN07896
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 4C2AD5E46E8;
+ Thu, 19 Aug 2004 07:10:45 -0300 (ADT)
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 67524-09; Thu, 19 Aug 2004 10:10:45 +0000 (GMT)
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by svr1.postgresql.org (Postfix) with ESMTP id 041D85E40BB;
+ Thu, 19 Aug 2004 07:10:45 -0300 (ADT)
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 294FC5E46C1
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 66409-09
+ Thu, 19 Aug 2004 10:04:27 +0000 (GMT)
+Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91])
+ by svr1.postgresql.org (Postfix) with ESMTP id 81BFB5E37CE
+Received: from mailgate.bray-healthcare.com ([80.177.250.202] helo=solport.bray-healthcare.com)
+ by anchor-post-33.mail.demon.net with esmtp (Exim 3.35 #1)
+ id 1BxjmR-000A7U-0X; Thu, 19 Aug 2004 10:04:23 +0000
+Received: from braydb.bray-healthcare.com ([192.168.1.18])
+ by solport.bray-healthcare.com with esmtp (Exim 3.36 #1 (Debian))
+ id 1BxjmR-0004jK-00; Thu, 19 Aug 2004 11:04:23 +0100
+Subject: Re: [GENERAL] pg_dump feature request: Exclude tables?
+Content-Type: text/plain
+Message-ID: <1092909858.19834.30.camel@braydb>
+MIME-Version: 1.0
+X-Mailer: Ximian Evolution 1.4.6
+Date: Thu, 19 Aug 2004 11:04:18 +0100
+Content-Transfer-Encoding: 7bit
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-general
+Precedence: bulk
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on
+ candle.pha.pa.us
+X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
+ version=2.61
+Status: OR
+
+On Wed, 2004-08-18 at 20:11, Glen Parker wrote:
+> > >Hmm, while you're at it, maybe you could make it accept wild
+> > >cards or regexp or something :-) That should allow you to toss
+> > >the -n parameter altogether (schema.*) if you wanted to.
+> > >
+> > >It would also be at least as good, IMO, to accept only one -t
+> > >option, re-defined as a comma-seperated list of names... And an
+> > >exlusion parameter defined the same way.
+> > >
+> > How would this interact with the shell? It seems like a supportability
+> > issue if we have to require single quotes around such arguments.
+>
+> I think wild cards would be extremely useful, but you're right, it can't be
+> required for common cases. Maybe "-t schema." could be shorthand for "-t
+> schema.*".
+
+Anyone who uses shell commands must already be familiar with the need to
+quote wildcard characters which are not meant for the shell. One major
+utility which requires this is find; others that spring to mind are dpkg
+-l and mmv. Anyone who doesn't get it will very soon be educated; I
+don't see this issue as a reason not to use such wildcards.
+
+Oliver Elphick
+
+
+
+---------------------------(end of broadcast)---------------------------
+TIP 9: the planner will ignore your desire to choose an index scan if your
+ joining column's datatypes do not match
+
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0H5OFw29490
+Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
+ by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j0H5O741023101;
+ Mon, 17 Jan 2005 00:24:08 -0500 (EST)
+Subject: Re: [HACKERS] pgdump
+ message dated "Mon, 17 Jan 2005 15:59:50 +1100"
+Date: Mon, 17 Jan 2005 00:24:07 -0500
+Status: OR
+
+> Something like the design elaborated here:
+
+> http://archives.postgresql.org/pgsql-patches/2004-07/msg00374.php
+
+> looks good to me, and would be preferrable to Andreas' patch IMHO.
+> Unless I'm missing something, I don't see a patch from David Skoll in
+> that thread that actually implements the above behavior. I'd be happy to
+> implement Tom's suggested design for 8.1 unless someone has already
+> beaten me to it.
+
+A little further down-thread there was some discussion of also allowing
+wild cards in the individual switches, eg
+
+ -t 's1.*'
+
+(This would differ from '-n s1' in that a -t switch would restrict the
+dump to tables only, whereas -n should take every sort of object in the
+selected schema.) I dismissed it at the time because we were too close
+to feature freeze, but the idea should be considered if you're going to
+do a new patch for 8.1. I think the issues would be
+
+* what are the wildcard rules exactly?
+* what about quoting/downcasing rules?
+
+Possibly it's sufficient to say "just like the way \d works in psql",
+but we should look closely before leaping. We've been burnt before
+by choosing rules that turned out to be awkward to use on a shell
+command line because of interference from the shell's quoting and
+expansion behavior.
+
+ regards, tom lane
+
+Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0H5lUw01573
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 890913A2BA1
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ Mon, 17 Jan 2005 05:47:23 +0000 (GMT)
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by svr1.postgresql.org (Postfix) with ESMTP id 863A53A2BDD
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 9FB6C3A2B46
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 32238-07
+ Mon, 17 Jan 2005 05:45:02 +0000 (GMT)
+Received: from sue.samurai.com (sue.samurai.com [205.207.28.74])
+ by svr1.postgresql.org (Postfix) with ESMTP id B24C13A2023
+Received: from localhost (localhost [127.0.0.1])
+ by sue.samurai.com (Postfix) with ESMTP id B8CD819890;
+ Mon, 17 Jan 2005 00:45:00 -0500 (EST)
+Received: from sue.samurai.com ([127.0.0.1])
+ by localhost (sue.samurai.com [127.0.0.1]) (amavisd-new, port 10024)
+ with LMTP id 35375-02-2; Mon, 17 Jan 2005 00:44:59 -0500 (EST)
+Received: from fjgateway (unknown [61.88.101.19])
+ by sue.samurai.com (Postfix) with ESMTP id 0D7D81988A;
+ Mon, 17 Jan 2005 00:44:57 -0500 (EST)
+Subject: Re: [HACKERS] pgdump
+Content-Type: text/plain
+Date: Mon, 17 Jan 2005 16:43:18 +1100
+MIME-Version: 1.0
+X-Mailer: Evolution 2.0.3
+Content-Transfer-Encoding: 7bit
+X-Virus-Scanned: by amavisd-new at mailbox.samurai.com
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-hackers
+Precedence: bulk
+X-Virus-Scanned: by amavisd-new at hub.org
+Status: OR
+
+On Mon, 2005-01-17 at 00:24 -0500, Tom Lane wrote:
+> A little further down-thread there was some discussion of also allowing
+> wild cards in the individual switches, eg
+>
+> -t 's1.*'
+>
+> (This would differ from '-n s1' in that a -t switch would restrict the
+> dump to tables only, whereas -n should take every sort of object in the
+> selected schema.)
+
+Is this actually useful behavior? My gut feeling is "no", but I'm open
+to debate. ISTM that the combination of "-n" and "-t" achieves a pretty
+wide swath of the desired functionality. Considering that the various
+combinations of these switches is already quite complex, I think it
+would be wise to avoid additional, unnecessary complications. Plus it
+avoids the need to play games with escaping the wildcard from the shell.
+
+> * what about quoting/downcasing rules?
+
+If we don't implement wildcards, I don't believe we will need to change
+the present behavior of the "-n" and "-t" switches WRT case conversion
+etc.
+
+-Neil
+
+
+
+---------------------------(end of broadcast)---------------------------
+TIP 7: don't forget to increase your free space map settings
+
+Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0H5tww02467
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 886D03A2951
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ Mon, 17 Jan 2005 05:55:53 +0000 (GMT)
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by svr1.postgresql.org (Postfix) with ESMTP id 9A2883A292A
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 185743A2C10
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 32471-06
+ Mon, 17 Jan 2005 05:54:28 +0000 (GMT)
+Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
+ by svr1.postgresql.org (Postfix) with ESMTP id B577B3A2C07
+Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
+ by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j0H5sN9V023361;
+ Mon, 17 Jan 2005 00:54:23 -0500 (EST)
+Subject: Re: [HACKERS] pgdump
+ message dated "Mon, 17 Jan 2005 16:43:18 +1100"
+Date: Mon, 17 Jan 2005 00:54:22 -0500
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-hackers
+Precedence: bulk
+X-Virus-Scanned: by amavisd-new at hub.org
+Status: OR
+
+> On Mon, 2005-01-17 at 00:24 -0500, Tom Lane wrote:
+>> A little further down-thread there was some discussion of also allowing
+>> wild cards in the individual switches,
+
+> Is this actually useful behavior?
+
+Possibly not. It's been requested often enough, but multiple -t and -n
+switches might be sufficient.
+
+>> * what about quoting/downcasing rules?
+
+> If we don't implement wildcards, I don't believe we will need to change
+> the present behavior of the "-n" and "-t" switches WRT case conversion
+> etc.
+
+I'm not sure you can ignore the issue completely. The proposal you're
+supporting included being able to pick out a specific table with
+ -t s1.t1
+and without any quoting rules it would then become impossible to deal
+with names containing dots. Are we willing to blow off that case?
+Or is it better to drop that part of the proposal?
+
+ regards, tom lane
+
+---------------------------(end of broadcast)---------------------------
+TIP 7: don't forget to increase your free space map settings
+
+Received: from sue.samurai.com (sue.samurai.com [205.207.28.74])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0H6B2w03949
+Received: from localhost (localhost [127.0.0.1])
+ by sue.samurai.com (Postfix) with ESMTP id BF6DB19896;
+ Mon, 17 Jan 2005 01:10:53 -0500 (EST)
+Received: from sue.samurai.com ([127.0.0.1])
+ by localhost (sue.samurai.com [127.0.0.1]) (amavisd-new, port 10024)
+ with LMTP id 35903-02-2; Mon, 17 Jan 2005 01:10:52 -0500 (EST)
+Received: from fjgateway (unknown [61.88.101.19])
+ by sue.samurai.com (Postfix) with ESMTP id 06A021988A;
+ Mon, 17 Jan 2005 01:10:50 -0500 (EST)
+Subject: Re: [HACKERS] pgdump
+Content-Type: text/plain
+Date: Mon, 17 Jan 2005 17:09:10 +1100
+MIME-Version: 1.0
+X-Mailer: Evolution 2.0.3
+Content-Transfer-Encoding: 7bit
+X-Virus-Scanned: by amavisd-new at mailbox.samurai.com
+Status: OR
+
+On Mon, 2005-01-17 at 00:54 -0500, Tom Lane wrote:
+> -t s1.t1
+> [...] without any quoting rules it would then become impossible to
+> deal with names containing dots.
+
+Ah, yeah -- sorry, I was focusing on case conversion rather than quoting
+in general.
+
+> Are we willing to blow off that case?
+> Or is it better to drop that part of the proposal?
+
+I would be OK with just ignoring this case, but on reflection I would
+prefer removing the "-t schema.table" syntax. Removing the feature
+resolves the quoting issue and also simplifies pg_dump's behavior. We
+lose the ability to dump table t1 in schema s1 and table t2 in schema s2
+in a single command, but
+
+(a) you can specify "-t t1 -t t2 -n s1 -n s2", although this might also
+dump t1.s2 and/or t2.s1
+
+(b) you can just run pg_dump twice, specifying the appropriate -t and -n
+options each time
+
+So the behavior would be that suggested earlier by David Skoll:
+
+> pg_dump -t t1 -- Dump table t1 in any schema
+> pg_dump -n s1 -- Dump all of schema s1
+> pg_dump -t t1 -n s1 -- Dump t1 in s1
+> pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2
+> pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2
+
+We'd only raise an error if we found no matching tables/schemas, as was
+hashed out in July.
+
+-Neil
+
+
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0H6Jgw04904
+Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
+ by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j0H6Jajs023583;
+ Mon, 17 Jan 2005 01:19:36 -0500 (EST)
+Subject: Re: [HACKERS] pgdump
+ message dated "Mon, 17 Jan 2005 17:09:10 +1100"
+Date: Mon, 17 Jan 2005 01:19:36 -0500
+Status: OR
+
+> So the behavior would be that suggested earlier by David Skoll:
+
+>> pg_dump -t t1 -- Dump table t1 in any schema
+>> pg_dump -n s1 -- Dump all of schema s1
+>> pg_dump -t t1 -n s1 -- Dump t1 in s1
+>> pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2
+>> pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2
+
+Well, that at least obeys the KISS principle ;-). Sure, let's try that
+and see if it satisfies people.
+
+Just to be clear: what I understand the logic to be is "OR" across
+multiple switches of the same type, but "AND" across switches of
+two types.
+
+ regards, tom lane
+
+Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0H6o4w07718
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 6A7FC3A2C10
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ Mon, 17 Jan 2005 06:49:55 +0000 (GMT)
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by svr1.postgresql.org (Postfix) with ESMTP id 830C53A2CC1
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 56D163A29AB
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 38357-02
+ Mon, 17 Jan 2005 06:48:29 +0000 (GMT)
+Received: from sue.samurai.com (sue.samurai.com [205.207.28.74])
+ by svr1.postgresql.org (Postfix) with ESMTP id F3D893A2951
+Received: from localhost (localhost [127.0.0.1])
+ by sue.samurai.com (Postfix) with ESMTP id 531841989B;
+ Mon, 17 Jan 2005 01:48:27 -0500 (EST)
+Received: from sue.samurai.com ([127.0.0.1])
+ by localhost (sue.samurai.com [127.0.0.1]) (amavisd-new, port 10024)
+ with LMTP id 37185-01-4; Mon, 17 Jan 2005 01:48:26 -0500 (EST)
+Received: from fjgateway (unknown [61.88.101.19])
+ by sue.samurai.com (Postfix) with ESMTP id 360F419898;
+ Mon, 17 Jan 2005 01:48:23 -0500 (EST)
+Subject: Re: [HACKERS] pgdump
+Content-Type: text/plain
+Date: Mon, 17 Jan 2005 17:46:39 +1100
+MIME-Version: 1.0
+X-Mailer: Evolution 2.0.3
+Content-Transfer-Encoding: 7bit
+X-Virus-Scanned: by amavisd-new at mailbox.samurai.com
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-hackers
+Precedence: bulk
+X-Virus-Scanned: by amavisd-new at hub.org
+Status: OR
+
+On Mon, 2005-01-17 at 01:19 -0500, Tom Lane wrote:
+> Just to be clear: what I understand the logic to be is "OR" across
+> multiple switches of the same type, but "AND" across switches of
+> two types.
+
+If I understand you correctly, you're suggesting that we should only
+report an error if none of the specified tables exist OR none of the
+specified schemas exist. I'm not sure I agree. Consider this command:
+
+pg_dump -t some_table -t non_existent_table
+
+Assuming some_table exists, we will now blithely ignore the nonexistent
+table. That is perfectly reasonable because of the cartesian explosion
+of possibilities that occurs when both -t and -n are specified, but in
+the absence of that it seems regrettable. The same applies to "-n foo -n
+non_existent_schema", naturally.
+
+An easy fix would be to raise an error for each specified but
+nonexistent object, *except* if both "-n" and "-t" are specified, in
+which case we use your behavior (report an error if none of the
+specified tables are found OR none of the specified schemas are found).
+Perhaps better would be to require that each "-t" or "-n" switch results
+in a 'match' -- i.e. if you specify "-t foo -n x -n y", we check that
+
+(a) schema x exists AND
+(b) schema y exists AND
+(c) table foo exists in (schema x OR schema y)
+
+This means we have tighter error checking, although I'm not sure how
+intuitive it is.
+
+-Neil
+
+
+
+---------------------------(end of broadcast)---------------------------
+TIP 4: Don't 'kill -9' the postmaster
+
+Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0H7gBw12676
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 910503A2C64
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ Mon, 17 Jan 2005 07:42:04 +0000 (GMT)
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by svr1.postgresql.org (Postfix) with ESMTP id A1F143A2BC5
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id 0E9C13A2C9C
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 45969-01
+ Mon, 17 Jan 2005 07:40:25 +0000 (GMT)
+Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
+ by svr1.postgresql.org (Postfix) with ESMTP id 0FD753A2990
+Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
+ by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j0H7eJs9024034;
+ Mon, 17 Jan 2005 02:40:20 -0500 (EST)
+Subject: Re: [HACKERS] pgdump
+ message dated "Mon, 17 Jan 2005 17:46:39 +1100"
+Date: Mon, 17 Jan 2005 02:40:19 -0500
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-hackers
+Precedence: bulk
+X-Virus-Scanned: by amavisd-new at hub.org
+Status: OR
+
+> On Mon, 2005-01-17 at 01:19 -0500, Tom Lane wrote:
+>> Just to be clear: what I understand the logic to be is "OR" across
+>> multiple switches of the same type, but "AND" across switches of
+>> two types.
+
+> If I understand you correctly, you're suggesting that we should only
+> report an error if none of the specified tables exist OR none of the
+> specified schemas exist.
+
+No, I was only expressing an opinion about what should be dumped,
+not about what kind of diagnostic messages to issue.
+
+If you want to warn about switches that fail to match anything,
+go for it. (I vote for just a warning, though, not a hard error.)
+
+ regards, tom lane
+
+---------------------------(end of broadcast)---------------------------
+TIP 5: Have you checked our extensive FAQ?
+
+ http://www.postgresql.org/docs/faqs/FAQ.html
+
+Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0HChHw19638
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id CB9053A3CA5
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ Mon, 17 Jan 2005 12:43:11 +0000 (GMT)
+Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
+ by svr1.postgresql.org (Postfix) with ESMTP id 902513A3C1B
+Received: from localhost (unknown [200.46.204.144])
+ by svr1.postgresql.org (Postfix) with ESMTP id B67B53A3B35
+Received: from svr1.postgresql.org ([200.46.204.71])
+ by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
+ with ESMTP id 93985-01
+ Mon, 17 Jan 2005 12:40:42 +0000 (GMT)
+Received: from mail.iinet.net.au (mail-02.iinet.net.au [203.59.3.34])
+ by svr1.postgresql.org (Postfix) with SMTP id B49F63A2C05
+Received: (qmail 11099 invoked from network); 17 Jan 2005 12:40:40 -0000
+Received: from unknown (HELO ?192.168.0.3?) (203.217.62.99)
+ by mail.iinet.net.au with SMTP; 17 Jan 2005 12:40:39 -0000
+Date: Mon, 17 Jan 2005 23:33:31 +1100
+User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
+X-Accept-Language: en-us, en
+MIME-Version: 1.0
+Subject: Re: [HACKERS] pgdump
+Content-Type: text/plain; charset=ISO-8859-1; format=flowed
+Content-Transfer-Encoding: 7bit
+X-Virus-Scanned: by amavisd-new at hub.org
+X-Mailing-List: pgsql-hackers
+Precedence: bulk
+X-Virus-Scanned: by amavisd-new at hub.org
+Status: OR
+
+Neil Conway wrote:
+
+>I would be OK with just ignoring this case, but on reflection I would
+>prefer removing the "-t schema.table" syntax. Removing the feature
+>resolves the quoting issue and also simplifies pg_dump's behavior. We
+>lose the ability to dump table t1 in schema s1 and table t2 in schema s2
+>in a single command, but
+>
+>(a) you can specify "-t t1 -t t2 -n s1 -n s2", although this might also
+>dump t1.s2 and/or t2.s1
+>
+>(b) you can just run pg_dump twice, specifying the appropriate -t and -n
+>options each time
+>
+>So the behavior would be that suggested earlier by David Skoll:
+>
+>
+>
+>>pg_dump -t t1 -- Dump table t1 in any schema
+>>pg_dump -n s1 -- Dump all of schema s1
+>>pg_dump -t t1 -n s1 -- Dump t1 in s1
+>>pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2
+>>pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2
+>>
+>>
+>
+>We'd only raise an error if we found no matching tables/schemas, as was
+>hashed out in July.
+>
+>
+I really prefer the -t "schema.table" syntax over the scenario listed
+above. If you look at the syntax for psql "\" commands, and SQL
+commands, the structure "tablename, optionally schema-qualified" is seen
+time and time again. By allowing the same structure in arguments to
+pg_dump, you're helping add to an overall feeling of consistency in the
+postgres toolbox.
+
+My feeling is that, to an occasional or novice user of pg_dump, the
+proposed combination of -n and -t will seem daunting and idiosyncratic,
+especially for complex cases.
+
+The fact that with -n -t there are some cases that are actually
+impossible to perform in a single dump is quite a powerful disadvantage
+IMO. Yes, you *can* just run pg_dump multiple times, but I think anyone
+using pg_dump would rather quote out a wilcard than issue virtually the
+same command with one changed argument over and over again. Or writing
+a script to loop through the desired schema/table combinations and
+dumping each one at a time.
+
+Is command line quoting really that much of a hassle? And if so, what
+are the major hurdles?
+
+---------------------------(end of broadcast)---------------------------
+TIP 4: Don't 'kill -9' the postmaster
+
projects / users / bernd / postgres.git / commitdiff