Re: [PATCHES] New pg_dump options: exclude tables/schemas, multiple all, wildcards
Greg Sabino Mullane wrote: Attached is a patch to hopefully make pg_dump a lot more useful. I started out by making it simply able to avoid dumping a single table, but, inspired by David Fetter's patch last November, also added in support for multiple items and limited wildcard matching. I wonder if there's a way to have the server process the matching? That way we could have LIKE expressions in the switches, which would be simpler in the code and more powerful. I don't know how pg_dump works so I can't really answer the question. We desperately need this capability however, as patches have been floating since before 8.0 and we still don't have it. -- Alvaro Herrera Developer, http://www.PostgreSQL.org Si quieres ser creativo, aprende el arte de perder el tiempo ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] message for constraint
I have added the following documentation addition to suggest this usage for constraint names. --- Jaime Casanova wrote: On 1/14/06, Peter Eisentraut [EMAIL PROTECTED] wrote: Jaime Casanova wrote: From time to time people ask me if there is a way to customize messages for constraints so they could be more informative to the user... What about this? = create table foo (fld int4 constraint fld must contain positive numbers check (fld 0)); CREATE TABLE = insert into foo values (-5); ERROR: new row for relation foo violates check constraint fld must contain positive numbers -- Peter Eisentraut http://developer.postgresql.org/~petere/ ok, i didn't know you can use such names... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: create_table.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v retrieving revision 1.96 retrieving revision 1.98 diff -c -c -r1.96 -r1.98 *** create_table.sgml 1 Nov 2005 21:09:50 - 1.96 --- create_table.sgml 16 Jan 2006 19:53:12 - 1.98 *** *** *** 293,300 termliteralCONSTRAINT replaceable class=PARAMETERconstraint_name/replaceable/literal/term listitem para ! An optional name for a column or table constraint. If not specified, ! the system generates a name. /para /listitem /varlistentry --- 293,304 termliteralCONSTRAINT replaceable class=PARAMETERconstraint_name/replaceable/literal/term listitem para ! An optional name for a column or table constraint. If the ! constraint is violated, the constraint name is present in error messages, ! so constraint names like literalcol must be positive/ can be used ! to communicate helpful constraint information to client applications. ! (Double-quotes are required for constraint names that contain spaces.) ! If not specified, the system generates a name. /para /listitem /varlistentry ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] message for constraint
On 1/16/06, Bruce Momjian pgman@candle.pha.pa.us wrote: I have added the following documentation addition to suggest this usage for constraint names. --- --- 293,304 termliteralCONSTRAINT replaceable class=PARAMETERconstraint_name/replaceable/literal/term listitem para ! An optional name for a column or table constraint. If the ! constraint is violated, the constraint name is present in error messages, ! so constraint names like literalcol must be positive/ can be used ! to communicate helpful constraint information to client applications. ! (Double-quotes are required for constraint names that contain spaces.) ! If not specified, the system generates a name. /para /listitem /varlistentry a lot better... thanx... what about lower the context part of the messages for plpgsql functions? that seems debug info for me... just an idea ;) pruebas=# select prueba(); ERROR: new row for relation foo violates check constraint foo_fld_check CONTEXT: SQL statement insert into foo values (-1) PL/pgSQL function prueba line 2 at SQL statement -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] message for constraint
On 1/16/06, Alvaro Herrera [EMAIL PROTECTED] wrote: Jaime Casanova wrote: On 1/16/06, Bruce Momjian pgman@candle.pha.pa.us wrote: what about lower the context part of the messages for plpgsql functions? that seems debug info for me... just an idea ;) pruebas=# select prueba(); ERROR: new row for relation foo violates check constraint foo_fld_check CONTEXT: SQL statement insert into foo values (-1) PL/pgSQL function prueba line 2 at SQL statement It's not debug info in the sense of the DEBUG error levels. These are meant as debug info of the server itself, like, say, a transaction started. The CONTEXT line is exactly that, context information. ok... maybe notice? log? i suppose that the ERROR line is error level so the idea is lowering the context so i can put client_min_messages='error' and see just what the user can understand... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] message for constraint
Jaime Casanova wrote: On 1/16/06, Bruce Momjian pgman@candle.pha.pa.us wrote: what about lower the context part of the messages for plpgsql functions? that seems debug info for me... just an idea ;) pruebas=# select prueba(); ERROR: new row for relation foo violates check constraint foo_fld_check CONTEXT: SQL statement insert into foo values (-1) PL/pgSQL function prueba line 2 at SQL statement It's not debug info in the sense of the DEBUG error levels. These are meant as debug info of the server itself, like, say, a transaction started. The CONTEXT line is exactly that, context information. -- Alvaro Herrerahttp://www.advogato.org/person/alvherre World domination is proceeding according to plan(Andrew Morton) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] ISBN-13 support
Hi, I have been searching for information on postgresql support of the new isbn-13 standard. I have used the isbn_issn extension in the contrib directory but I don't believe that it supports the new isbn-13 standard. I'm not a C programmer so can't work on the isbn_issn extension myself, but I just wanted to let the group know about the changes that are happening with the standard and provide some of the information I have found: ISBN-13 Details http://www.isbn.org/toolkit.html http://www.isbn-international.org/converter/converter.html http://www.isbn-international.org/en/revision.html Postgresql Activitity This user seems to have started some work on it. http://archives.postgresql.org/pgsql-hackers/2004-11/msg00153.php Cheers, Benjamin Wragg -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.19/231 - Release Date: 16/01/2006
Re: [PATCHES] Index padding optimization
Tom Lane [EMAIL PROTECTED] wrote: This seems extremely invasive for a relatively small gain :-( The example you cite of an int4 index on a MAXALIGN-8 machine is by far the best case, and in many cases there wouldn't be anything bought by the extra complexity. I also think that it has small advantage without another compression method. But if we tries to compress index keys using prefix compression or so, we might need to put tuples with no/small alignment. I would like to propose it again when I find another method which will work well with this patch. --- ITAGAKI Takahiro NTT Cyber Space Laboratories ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] patch to create system view that lists cursors
On Sun, 2006-01-15 at 17:57 -0500, Neil Conway wrote: I think the view should include the portals created by DECLARE CURSOR and Bind protocol messages, but should not include the unnamed portal or any other portals that are created internally as part of the implementation of other commands (e.g. EXECUTE). I'm not sure how to handle SPI: developers using SPI would expect to find their portals in the view, but those using SPI indirectly (e.g. via PL/foo) would probably find the clutter surprising. I'd say we need to include SPI portals in the view as well. Attached is a revised version of Joachim's patch that implements this. Cursors created via SPI are part of the view, which produces somewhat unexpected results when querying the view from a procedural language as noted above, but I suppose it's the best compromise. The documentation still needs some work. Barring any objections, I'll fix that and a few other minor issues and then apply the patch tomorrow. -Neil *** doc/src/sgml/catalogs.sgml 4eec167450469237ea89094c7bc90511b4d0ebdf --- doc/src/sgml/catalogs.sgml 5d0f61713e050a48b4f6217d4e20db444ffb20b1 *** *** 4360,4365 --- 4360,4370 tbody row + entrylink linkend=view-pg-cursorsstructnamepg_cursors/structname/link/entry + entryopen cursors/entry + /row + + row entrylink linkend=view-pg-groupstructnamepg_group/structname/link/entry entrygroups of database users/entry /row *** *** 4429,4434 --- 4434,4533 /table /sect1 + sect1 id=view-pg-cursors + titlestructnamepg_cursors/structname/title + + indexterm zone=view-pg-cursors +primarypg_cursors/primary + /indexterm + + para +The view structnamepg_cursors/structname lists all declared cursors for +the current session and transaction. Note that cursors that have been +declared literalWITHOUT HOLD/literal are only valid within the current +transaction whereas literalWITH HOLD/literal cursors can exist during +the whole session. Cursors can be created using xref linkend=sql-declare +endterm=sql-declare-title and removed with xref linkend=sql-close +endterm=sql-close-title. + /para + + table +titlestructnamepg_cursors/ Columns/title + +tgroup cols=4 + thead + row + entryName/entry + entryType/entry + entryReferences/entry + entryDescription/entry + /row + /thead + + tbody + row + entrystructfieldname/structfield/entry + entrytypetext/type/entry + entry/entry + entryThe name of the cursor/entry + /row + + row + entrystructfieldstatement/structfield/entry + entrytypetext/type/entry + entry/entry + entryThe verbatim query string submitted to declare this cursor/entry + /row + + row + entrystructfieldis_holdable/structfield/entry + entrytypeboolean/type/entry + entry/entry + entry +literaltrue/literal if the cursor is holdable (that is, it +can be accessed after the transaction that declared the cursor +has committed); literalfalse/literal otherwise +/entry + /row + + row + entrystructfieldis_binary/structfield/entry + entrytypeboolean/type/entry + entry/entry + entry +literaltrue/literal if the cursor was declared +literalBINARY/literal; literalfalse/literal +otherwise !-- XXX: discuss fe/be protocol -- +/entry + /row + + row + entrystructfieldis_scrollable/structfield/entry + entrytypeboolean/type/entry + entry/entry + entry +literaltrue/ if the cursor is scrollable (that is, it +allows rows to be retrieved in a nonsequential manner); +literalfalse/literal otherwise +/entry + /row + + row + entrystructfieldcreation_time/structfield/entry + entrytypetimestamptz/type/entry + entry/entry + entryThe time at which the cursor was declared/entry + /row + /tbody +/tgroup + /table + + para +The structnamepg_cursors/structname view is read only. + /para + + /sect1 + sect1 id=view-pg-group titlestructnamepg_group/structname/title *** doc/src/sgml/ref/close.sgml 8892a94e8d7e93d729efc7f45f5f65fa47e26854 --- doc/src/sgml/ref/close.sgml e430bd034f8fd5b8a97f81063f2f9f5a7edf3891 *** *** 76,81 --- 76,86 xref linkend=sql-declare endterm=sql-declare-title statement to declare a cursor. /para + + para +You can see all available cursors by querying the +structnamepg_cursors/structname system view. + /para /refsect1 refsect1 *** doc/src/sgml/ref/declare.sgml
Re: [PATCHES] TupleDesc refcounting
On Sun, 2006-01-15 at 12:08 -0500, Tom Lane wrote: My inclination at this point is to forget the whole thing and just patch the callers of lookup_rowtype_tupdesc that need to copy the tupdesc. Actually, I think I finally understand how to implement this patch sanely. I had thought that the lifetime of a TupleDesc should be dictated by either the memory context in which it is allocated, OR its reference count. This leads us down the road toward mandatory reference counting, which I agree is a net loss. However, since we're primarily concerned with TupleDescs allocated in CacheMemoryContext and that context is never reset, we can use the reference count *just* to manage the external references to TupleDescs. That should make the patch far less invasive. (I have the feeling you've been suggesting this all along, I've just been too thick-skulled to understand you.) I'll hopefully have a patch implementing this finished by tomorrow evening. -Neil ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
