Re: [HACKERS] Bogus TODO item
On Wed, Aug 20, 2008 at 9:15 PM, Bruce Momjian [EMAIL PROTECTED] wrote: Tom Lane wrote: Idly thumbing through the new TODO list, I noticed that the second item from the bottom (about how we don't want optional AS) has been superseded by events ... http://archives.postgresql.org/pgsql-committers/2008-02/msg00172.php Good point, removed. I didn't mark it as done becuase it is unclear what done means for a not wanted item. ;-) Done away with. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Questions about HeapTupleHeaderData
Tom Lane napsal(a): Zdenek Kotala [EMAIL PROTECTED] writes: I try to understand why HeapTupleHeaderData structure has t_datum member. This is use only on few places and from my point of view this information should be stored in the HeapTupleData structure or split HeapTupleHeaderData it into two structures (DatumTupleHeaderData). Then (a) we'd have two struct definitions that have to stay in sync and (b) we'd have to cast between HeapTupleHeader and DatumTupleHeader pointer types in a bunch of places, adding notational messiness with no advantage. If I understand correctly then for read path (select) tuple is always HeapTuple, because we need support select xmax ... And DatumTuple is used for write path (insert/update) and it is converted to HeapTuple in heap_insert/heap_update function. Hmm I'm looking into executor and executor converts it when tuple is copied from buffer to work memory and processed. However, Other kind of question is about space optimization. From composite data type point of view it seems to me that we waste a lot of space. For example varlena is always 4 bytes and from infomask we need only HASVARWIDTH, HEAP_HASEXTERNAL and HASNULLS which could be placed into infomask2 and all transaction information should be in infomask. By my opinion we can save minimal 8 bytes there per composite type with reordering and of course minimal tuple could be smaller too. OK any this changes bump page layout version which is not my goal now, but it could be idea for future development. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A smaller default postgresql.conf
David Fetter wrote: And we're back to man pages and CHM files. How big a project would that latter be? CHM files already exist. (At least I think that CHM == HTML Help == Windows help system.) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] migrate data 6.5.3 - 8.3.1
Tom Lane wrote: Of course, since you got the data migrated you might not care anymore. That's what i've done: 1. pg_dump database from 6.5.3 2. iconv from windows-1251 charset to utf-8. 3. cutted all AGGREGATEs 4. succesefully imported all data to 8.3.1 without errors. Seems to me everything now working as it should. Thanks everyone :) -- alexander lunyov -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A smaller default postgresql.conf
David Fetter wrote:
And we're back to man pages and CHM files.
So, did anyone else try to generate man pages? I did make man and ran
into several issues.
The first is that D2MDIR needs to be specified manually. I assume this
is how everyone does it, so I did that.
The second is that the Perl script as packaged by Debian doesn't work --
it is missing a handful of HTML entities, and it errors out before
generating anything. I had to patch it thusly:
*** docbook2man-spec.pl.orig2008-08-21 08:56:20.0 -0400
--- docbook2man-spec.pl 2008-08-19 18:13:22.0 -0400
***
*** 1177,1182
--- 1177,1192
man_sgml('|[copy ]|', '(C)');
man_sgml('|[nbsp ]|', '\~');
man_sgml('|[thinsp]|', '\~');
+ man_sgml('|[mdash ]|', '--');
+ man_sgml('|[pi]|', 'pi');
+ man_sgml('|[ntilde]|', 'ñ');
+ man_sgml('|[aacute]|', 'á');
+ man_sgml('|[oacute]|', 'ó');
+ man_sgml('|[bull ]|', 'X');
+ man_sgml('|[quot ]|', '');
+ man_sgml('|[scaron]|', 'š');
+ man_sgml('|[oslash]|', 'ø');
+ man_sgml('|[ouml ]|', 'ö');
#
# Default handlers (uncomment these if needed). Right now, these are set
The third problem I ran into is that manpages that are supposed to go
into the l section do not; the filename ends in a dot:
$ ls | tail -10
SPI_saveplan.
SPI_scroll_cursor_fetch.
SPI_scroll_cursor_move.
START TRANSACTION.
TRUNCATE.
UNLISTEN.
UPDATE.
VACUUM.
VALUES.
version.sgml
The makefile is passing --section l so I'm not sure what's going wrong
here.
And lastly, I couldn't figure out what decides which manpages are
generated, to make it pick the text we want to publish.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] About a message when pg_ctl -w start failed
Hi. When we perform pg_ctl -w start, postgres try to connect to postgres-database until timeout. If a user who perform pg_ctl -w start does not have authority to connect postgres-database, pg_ctl will return 1 and show could not start server message. But, in fact server is already starting. Therefore, users sometimes confuse. I think that if we failed on test_postmaster_connection(), pg_ctl might want to return 0 and show the message like following... server starting, but could not connect server. Check your authority. Your thoughts? Best regards. -- Tatsuhito Kasahara [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About a message when pg_ctl -w start failed
Tatsuhito Kasahara [EMAIL PROTECTED] writes: If a user who perform pg_ctl -w start does not have authority to connect postgres-database, pg_ctl will return 1 and show could not start server message. pg_ctl is already set up to recognize bad-password errors as meaning the postmaster is up. You didn't say what auth method you are using, but I'd think the right fix is to make it recognize other types of authentication failures as well. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Questions about HeapTupleHeaderData
Zdenek Kotala [EMAIL PROTECTED] writes: If I understand correctly then for read path (select) tuple is always HeapTuple, because we need support select xmax ... And DatumTuple is used for write path (insert/update) and it is converted to HeapTuple in heap_insert/heap_update function. No, DatumTuple is used for any free-standing composite-type Datum. Thinking about it as write path and read path seems to me to be missing the mark entirely. In general most tuple-reading code is supposed to work with either. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A smaller default postgresql.conf
Alvaro Herrera wrote: So, did anyone else try to generate man pages? Before we get too excited here: Man pages are only built/buildable from refentry elements. You can't just go and convert some arbitrary section or chapter into a man page. So there is a bit of work and invention necessary here. Offhand I'd try writing an XSLT script that can convert the chapter to the required refentry structure and go from there. I did make man and ran into several issues. The first is that D2MDIR needs to be specified manually. I assume this is how everyone does it, so I did that. True, because there is no standard place for it. And throughout most of history, you needed a locally built version anyway. The second is that the Perl script as packaged by Debian doesn't work -- it is missing a handful of HTML entities, and it errors out before generating anything. The packaging situation on Debian is quite weird. (See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275715) I suggest you download docbook2man-sgmlspl-1.0.tar.gz from upstream (docbook2x.sf.net) and install it (configure, make, make install). Then with make man D2MDIR=/usr/local/bin I get plausible output. There are indeed a few entities missing, but I think that is not really important because they appear in the areas that are not converted to the man pages. If there is interest in sorting out this tools mess, then I suggest also exploring converting the entire thing to use the new XML-based docbook2x tools. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Proposal: new border setting in psql
Here is a simple select output. darcy=# select title_id, title_name from title; title_id | title_name --+ 2 | Mrs 3 | Ms 4 | Miss (3 rows) Now I change the border. darcy=# \pset border 2 Border style is 2. darcy=# select title_id, title_name from title; +--++ | title_id | title_name | +--++ |2 | Mrs| |3 | Ms | |4 | Miss | +--++ (3 rows) I would like to propose a new border setting. darcy=# \pset border 3 Border style is 3. darcy=# select title_id, title_name from title; +--++ | title_id | title_name | +==++ |2 | Mrs| +--++ |3 | Ms | +--++ |4 | Miss | +--++ (3 rows) The reason for this is to allow the output to be fed directly into any system using Restructured text as described in http://docutils.sourceforge.net/docs/user/rst/quickref.html. If there is any interest I will submit patches for code and documentation. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki
Alvaro Herrera wrote: The new official location for the TODO list is here: http://wiki.postgresql.org/wiki/Todo:Todo What is it with this strange page naming? Have we not established some time ago that the colon is only supposed to be used for metapages? We kind of blew this on the commit fest pages, but at least new content should do it right. Plus, a URL such as http://wiki.postgresql.org/wiki/Todo would be a lot more obvious to find. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki
Peter Eisentraut wrote: Alvaro Herrera wrote: The new official location for the TODO list is here: http://wiki.postgresql.org/wiki/Todo:Todo What is it with this strange page naming? I agree with your argument. I think we inherited this name from a very old attempt to do the conversion, and just didn't worry about it very much, being too stressed about pleasing Bruce with the new format ;-) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki
Peter Eisentraut wrote: Plus, a URL such as http://wiki.postgresql.org/wiki/Todo would be a lot more obvious to find. Moved. The old name is kept as a redirect. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] postgres-R
Hi, Marcelo Martins wrote: Anyone knows a link that has some docs about how to get that setup ? Besides the README and other documentation in the source, there's admittedly not much. Check the archive of this mailing list. Also is it stable enough for production ? No. I though getting postgreSQL from CVS and compiling was not such a good idea since the CVSROOT is probably not stable, is that wrong ? Generally, that's a reasonable approach if you want to get stable software. However, Postgres-R is still in development, and there's no stable version. When taking snapshots, I'm only checking if Postgres-R still compiles. since I could not find info out there this is what I have done to check it out and I downloaded the postgres-r snapshoot patch snapshot 2008-08-13 88 kbpostgres-r-20080813.diff.bz2 cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot checkout -D 2008-08-13 -P pgsql Any comment much appreciated That sounds like the right thing to do if you want to peek at the source code or test-drive the prototype. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new border setting in psql
D'Arcy J.M. Cain [EMAIL PROTECTED] writes: I would like to propose a new border setting. That code is horrendously overcomplicated and unreadable already :-( I'm not too eager to add more variants to it. The reason for this is to allow the output to be fed directly into any system using Restructured text as described in http://docutils.sourceforge.net/docs/user/rst/quickref.html. Is that *really* going to work? What about quoting/escaping conventions? Also, how many of those any systems actually exist? Markup conventions are a dime a dozen. On the whole I think it ought to be sufficient to support XML output for people who want easily-machine-readable query output. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki
Alvaro Herrera [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Plus, a URL such as http://wiki.postgresql.org/wiki/Todo would be a lot more obvious to find. Moved. The old name is kept as a redirect. Pls make doc/TODO match. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: patch to create explicit support for semi and anti joins
Tom Lane [EMAIL PROTECTED] wrote: Introduce JOIN_SEMI and JOIN_ANTI join types, the former replacing JOIN_IN. Unify the InClauseInfo and OuterJoinInfo infrastructure into SpecialJoinInfo. Convert IN, EXISTS, and NOT EXISTS clauses at top level of WHERE into semi and anti joins respectively. It just struck me that this may cause additional joins to count against the join_collapse_limit. If so, that could cause some borderline queries to optimize poorly if the limit isn't raised. Is that a reasonable concern? Possibly something to document in the release notes? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new border setting in psql
On Thu, 21 Aug 2008 15:03:23 -0400 Tom Lane [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain [EMAIL PROTECTED] writes: I would like to propose a new border setting. That code is horrendously overcomplicated and unreadable already :-( I'm not too eager to add more variants to it. Actually, I already made the code changes and they were surprisingly simple. The reason for this is to allow the output to be fed directly into any system using Restructured text as described in http://docutils.sourceforge.net/docs/user/rst/quickref.html. Is that *really* going to work? What about quoting/escaping conventions? ReST is pretty good with that stuff. Also, how many of those any systems actually exist? Markup conventions are a dime a dozen. That I can't say. My impression was that it was reasonably well known. However, while ReST was *my* reason for proposing this it was also important to me that the format stand by itself. I think it does. It also follows the documentation in that it is an extension to border 2 but with more borders, just like border 2 is more than border 1, etc. It's a consistent progression. On the whole I think it ought to be sufficient to support XML output for people who want easily-machine-readable query output. Perhaps. The problem is that it still means running it through an external program. That's fine for scripted processes but not for ad hoc queries. Perhaps what we really need is the ability for users to install their own formatting functions. After all, we can define everything else. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal sql: labeled function params
Would AS be harder to implement? select foo(10 AS a, 20 AS b); select foo(20 AS b, 20 AS a); select x(0 = 1 AS a); other fantasies select foo(10 a, 20 b); select foo(a 10, b 20); regards, Asko On Wed, Aug 20, 2008 at 4:26 PM, Pavel Stehule [EMAIL PROTECTED]wrote: 2008/8/20 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: I understand now why Oracle use = symbol for named params. This isn't used so operator - so implementation is trivial. You really didn't understand the objection at all, did you? The point is not about whether there is any built-in operator named =. The point is that people might have created user-defined operators named that. I understand well, so only I don't see better solution. Yes, everyone who used = should have problems, but it is similar with .. new keywords, etc. Probably easy best syntax doesn't exist :(. I haven't idea who use = now and how often, and if this feature is possible in pg, but there are not technical barriers. regards Pavel Stehule regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Plus, a URL such as http://wiki.postgresql.org/wiki/Todo would be a lot more obvious to find. Moved. The old name is kept as a redirect. Pls make doc/TODO match. Done. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new border setting in psql
Proposed formats don't look easier to read for humans. I doubt that they are more common or easier to process by machines than just COPY query TO STDOUT CSV; The reason for this is to allow the output to be fed directly into any system using Restructured text The idea would be to use psql as backend for some other system? Or what do you mean by fed directly? On Thu, Aug 21, 2008 at 10:54 PM, D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: On Thu, 21 Aug 2008 15:03:23 -0400 Tom Lane [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain [EMAIL PROTECTED] writes: I would like to propose a new border setting. That code is horrendously overcomplicated and unreadable already :-( I'm not too eager to add more variants to it. Actually, I already made the code changes and they were surprisingly simple. The reason for this is to allow the output to be fed directly into any system using Restructured text as described in http://docutils.sourceforge.net/docs/user/rst/quickref.html. Is that *really* going to work? What about quoting/escaping conventions? ReST is pretty good with that stuff. Also, how many of those any systems actually exist? Markup conventions are a dime a dozen. That I can't say. My impression was that it was reasonably well known. However, while ReST was *my* reason for proposing this it was also important to me that the format stand by itself. I think it does. It also follows the documentation in that it is an extension to border 2 but with more borders, just like border 2 is more than border 1, etc. It's a consistent progression. On the whole I think it ought to be sufficient to support XML output for people who want easily-machine-readable query output. Perhaps. The problem is that it still means running it through an external program. That's fine for scripted processes but not for ad hoc queries. Perhaps what we really need is the ability for users to install their own formatting functions. After all, we can define everything else. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki
Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Plus, a URL such as http://wiki.postgresql.org/wiki/Todo would be a lot more obvious to find. Moved. The old name is kept as a redirect. Pls make doc/TODO match. The TODO link on the developer page needs to be updated too: http://www.postgresql.org/developer/ -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new border setting in psql
On Thu, 21 Aug 2008 23:22:28 +0300 Asko Oja [EMAIL PROTECTED] wrote: The idea would be to use psql as backend for some other system? Or what do you mean by fed directly? No, I meant that one would do any ad hoc query and cut and paste the output directly into a tracking tool that supports ReST. As I explained in another message though, this is a nice side effect for me and is the reason that I have an interest in coding it but it really is a logical extension of what we have anyway. Look how simple the documentation change would be. If you left out the extra example it's a one line difference. Index: src/sgml/ref/psql-ref.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.209 diff -u -p -u -r1.209 psql-ref.sgml --- src/sgml/ref/psql-ref.sgml 3 Jul 2008 03:37:16 - 1.209 +++ src/sgml/ref/psql-ref.sgml 21 Aug 2008 20:31:24 - @@ -1570,7 +1570,7 @@ lo_import 152801 acronymHTML/acronym mode, this will translate directly into the literalborder=.../literal attribute, in the others only values 0 (no border), 1 (internal dividing lines), - and 2 (table frame) make sense. + 2 (table frame) and 3 (individual cells) make sense. /para /listitem /varlistentry @@ -2973,6 +2973,22 @@ [EMAIL PROTECTED] testdb=gt; userinputS +---++ (4 rows) [EMAIL PROTECTED] testdb=gt; userinput\pset border 3/userinput +Border style is 3. [EMAIL PROTECTED] testdb=gt; userinputSELECT * FROM my_table;/userinput ++---++ +| first | second | ++===++ +| 1 | one| ++---++ +| 2 | two| ++---++ +| 3 | three | ++---++ +| 4 | four | ++---++ +(4 rows) + [EMAIL PROTECTED] testdb=gt; userinput\pset border 0/userinput Border style is 0. [EMAIL PROTECTED] testdb=gt; userinputSELECT * FROM my_table;/userinput -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing
Added to TODO: Eliminate de-TOASTing of values when not needed --- Tom Lane wrote: Attached is a worked-out patch for the approach proposed here: http://archives.postgresql.org/pgsql-hackers/2008-06/msg00777.php namely, that cache management for de-TOASTed datums is handled by TupleTableSlots. To avoid premature detoasting of values that we might never need, the patch introduces a concept of an indirect TOAST pointer, which has the same 0x80 or 0x01 header as an external TOAST pointer, but can be told apart by having a different length byte. Within that we have * pointer to original toasted field within the Slot's tuple * pointer to the owning Slot * pointer to decompressed copy, or NULL if not decompressed yet Some fairly straightforward extensions to the TupleTableSlot code, heaptuple.c, and tuptoaster.c make it all go. My original thoughts had included turning FREE_IF_COPY() into a no-op, but on investigation that seems impractical. One case that still depends on that pfree is where we have palloc'd a 4-byte-header copy of a short-header datum to support code that needs properly aligned datum content. The solution adopted in the patch is to arrange for pfree() applied to a cacheable detoasted object to be a no-op, whereas it still works normally for non-cached detoasted objects. We do this by inserting a dummy chunk header that points to a dummy memory context whose pfree support method does nothing. I think this part of the patch would be required for any toast caching method, not just this one. What I like about this patch is that it's a fairly small-footprint change, it doesn't add much overhead, and it covers caching of decompression for in-line-compressed datums as well as the out-of-line case. One thing I really *don't* like about it is that it requires everyplace that copies Datums to know about indirect pointers: in general, the copy must be a copy of the original toasted Datum, not of the indirect pointer, else we have indirect pointers that can outlive their owning TupleTableSlot (or at least outlive its current tuple cycle). There only seem to be about half a dozen such places in the current code, but still it seems a rather fragile coding rule. After playing with it for a little bit, I'm not convinced that it buys enough performance win to be worth applying --- the restriction of cache lifespan to one tuple cycle of a TupleTableSlot is awfully restrictive. (For example, sorts that involve toasted sort keys continue to suck, because the tuples being sorted aren't in Slots.) It would probably fix the specific case that the PostGIS hackers were complaining of, but I think we need something more. Still, I wanted to get it into the archives because the idea of indirect toast pointers might be useful for something else. regards, tom lane Content-Description: toast-indirect-1.patch.gz [ Type application/octet-stream treated as attachment, skipping... ] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki
Bruce Momjian wrote: The TODO link on the developer page needs to be updated too: http://www.postgresql.org/developer/ Done too (and a few other links to the TODO list that are on the website). Minor nit: the summer of code page says that the easy items are marked with a %, but that's no longer true. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Difference when using ZIC vs. Timezone Abbr - Bug?
These two queries produce different output, using version 8.3.3: SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'MDT'; SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'America/Boise'; ..is this a bug? Note: America/Boise=MDT (from pg_timezone_names) Best regards, -- Dave Witt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
A Dimecres 20 Agost 2008, Alvaro Herrera va escriure: Hi, Thanks to Brendan Jurd, who spent a lot of effort in creating useful Mediawiki templates, we now have moved the TODO list to the Wiki site. The new official location for the TODO list is here: http://wiki.postgresql.org/wiki/Todo:Todo Any chance of changing Easier and Done marks to others easier to find by a simple search with the browser? Maybe [E] and [D] would do. The old list had the same problem IMHO. I hereby kindly request the WWW team to update any references to point to the new address; perhaps install a redirection in http://www.postgresql.org/docs/faqs.TODO.html to the new location. The move has been approved by Bruce, the current maintainer. I hope that he continues to maintain the new version. While many details have been sorted out during the move, being a wiki there is nothing set in stone. Feel free to do changes like improve the markup or the templates so that things look better (after appropriate discussion), but if you intend to make changes like mark items completed, add new items, or remove items, please email pgsql-hackers as has been Bruce's tradition. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Albert Cervera i Areny http://www.NaN-tic.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Does anything dump per-database config settings? (was Re: [HACKERS] ALTER DATABASE vs pg_dump)
We never came up with any idea of how pg_dump could dump ALTER DATABASE ... SET commands, so I have added a mention in the documentation, and backpatched to 8.3.X; attached. --- Richard Huxton wrote: Robert Treat wrote: On Tuesday 01 July 2008 03:45:44 Richard Huxton wrote: The only time we need to restore per-database settings is if the database has been dropped. If you're not having the dump/restore re-create the database then presumably you've taken charge of the per-database settings. I'm not sure I agree with that entirely. For example, one common usage scenario when upgrading between major versions is to create the database, load contrib modules (whose C functions or similar may have changed), and then load the dump into the database. In those case you still might want the database settings to be dumped, even though you are creating the database manually. (Now, one might argue that you could still dump with --create and ignore the error of the database creation command, but that probably isn't ideal). Well, with -Fc I'd expect it to be dumped all the time and pg_restore would selectively restore it. That should mean it has its own line in the pg_restore --list output which would let you just comment out the database-creation but leave the ALTER...SET in. -- Richard Huxton Archonet Ltd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/ref/pg_dump.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v retrieving revision 1.103 diff -c -c -r1.103 pg_dump.sgml *** doc/src/sgml/ref/pg_dump.sgml 20 Jul 2008 18:43:30 - 1.103 --- doc/src/sgml/ref/pg_dump.sgml 21 Aug 2008 22:11:32 - *** *** 754,775 /para para !applicationpg_dump/application has a few limitations: ! !itemizedlist ! listitem ! para ! When a data-only dump is chosen and the option ! option--disable-triggers/ is used, ! applicationpg_dump/application emits commands to disable ! triggers on user tables before inserting the data and commands ! to re-enable them after the data has been inserted. If the ! restore is stopped in the middle, the system catalogs might be ! left in the wrong state. ! /para ! /listitem ! !/itemizedlist /para para --- 754,766 /para para !applicationpg_dump/application has a limitation; when a !data-only dump is chosen and the option option--disable-triggers/ !is used, applicationpg_dump/application emits commands !to disable triggers on user tables before inserting the data !and commands to re-enable them after the data has been !inserted. If the restore is stopped in the middle, the system !catalogs might be left in the wrong state. /para para *** *** 782,792 /para para !The dump file produced by applicationpg_dump/application does !not contain the statistics used by the optimizer to make query !planning decisions. Therefore, it is wise to run !commandANALYZE/command after restoring from a dump file to !ensure good performance. /para para --- 773,786 /para para !The dump file produced by applicationpg_dump/application !does not contain the statistics used by the optimizer to make !query planning decisions. Therefore, it is wise to run !commandANALYZE/command after restoring from a dump file !to ensure good performance. The dump file also does not !contain any commandALTER DATABASE ... SET/ commands; !these settings are dumped by xref linkend=app-pg-dumpall, !along with database users and other installation-wide settings. /para para -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] Surprising syntax error
Added to TODO: Allow GRANT/REVOKE on views to use the VIEW keyword rather than just TABLE http://archives.postgresql.org/pgsql-hackers/2008-06/msg01133.php --- Bruce Momjian wrote: Marc Munro wrote: -- Start of PGP signed section. The statement: revoke all on view internal.all_objects from public; yields a syntax error. The docs show that the word view is not acceptable in this statement which is fine but the surprising thing is that: ? revoke all on table internal.all_objects from public; works fine even though all_objects is a view and not a table. Now that I know about it, this doesn't bother me but it was a surprise and I wonder whether the the parser/planner/whatever should be a bit smarter about allowing the word table to apply to non-tables, and whether the word view ought to be allowed. Yes, I can confirm this behavior on CVS HEAD, and it is odd: test= CREATE SCHEMA internal; CREATE SCHEMA test= CREATE VIEW internal.all_objects AS SELECT 1; CREATE VIEW test= REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC; ERROR: syntax ERROR AT OR near internal LINE 1: REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC; ^ test= REVOKE ALL ON TABLE internal.all_objects FROM PUBLIC; REVOKE Is there a downside to adding VIEW in parser/gram.y:privilege_target? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
Albert Cervera i Areny wrote: A Dimecres 20 Agost 2008, Alvaro Herrera va escriure: Hi, Thanks to Brendan Jurd, who spent a lot of effort in creating useful Mediawiki templates, we now have moved the TODO list to the Wiki site. The new official location for the TODO list is here: http://wiki.postgresql.org/wiki/Todo:Todo Any chance of changing Easier and Done marks to others easier to find by a simple search with the browser? Maybe [E] and [D] would do. The old list had the same problem IMHO. The current idea Brendan has is to use a green circle for easy and a check mark for done. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
A Divendres 22 Agost 2008, Bruce Momjian va escriure: Albert Cervera i Areny wrote: A Dimecres 20 Agost 2008, Alvaro Herrera va escriure: Hi, Thanks to Brendan Jurd, who spent a lot of effort in creating useful Mediawiki templates, we now have moved the TODO list to the Wiki site. The new official location for the TODO list is here: http://wiki.postgresql.org/wiki/Todo:Todo Any chance of changing Easier and Done marks to others easier to find by a simple search with the browser? Maybe [E] and [D] would do. The old list had the same problem IMHO. The current idea Brendan has is to use a green circle for easy and a check mark for done. That doesn't make it easily searchable. Maybe I'm the only one, but every now and then I take a look at it, and there's no fast way of seeing what items have been done (and marked as easier). -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Albert Cervera i Areny http://www.NaN-tic.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
Albert Cervera i Areny wrote: A Divendres 22 Agost 2008, Bruce Momjian va escriure: Albert Cervera i Areny wrote: A Dimecres 20 Agost 2008, Alvaro Herrera va escriure: Hi, Thanks to Brendan Jurd, who spent a lot of effort in creating useful Mediawiki templates, we now have moved the TODO list to the Wiki site. The new official location for the TODO list is here: http://wiki.postgresql.org/wiki/Todo:Todo Any chance of changing Easier and Done marks to others easier to find by a simple search with the browser? Maybe [E] and [D] would do. The old list had the same problem IMHO. The current idea Brendan has is to use a green circle for easy and a check mark for done. That doesn't make it easily searchable. Maybe I'm the only one, but every now and then I take a look at it, and there's no fast way of seeing what items have been done (and marked as easier). That is true, but text like E merges into the adjacent words. Frankly the puctuation symbols were a good solution, but not as slick as the bullet/checkmark suggestion. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
Bruce Momjian escribió: Albert Cervera i Areny wrote: That doesn't make it easily searchable. Maybe I'm the only one, but every now and then I take a look at it, and there's no fast way of seeing what items have been done (and marked as easier). That is true, but text like E merges into the adjacent words. Frankly the puctuation symbols were a good solution, but not as slick as the bullet/checkmark suggestion. They did not merge with the text, but they were not searchable. May I suggest using the text [easy] and [done] instead? That way, it is searchable, and they don't merge with the text. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Confusing message in log file
Wording adjusted and applied with attached patch.
---
Gurjeet Singh wrote:
On Mon, Jun 30, 2008 at 7:33 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
In any case, this seems a case of stuffing too much in the primary
message.
Yeah, good point.
I think it should be something like
errmsg(parameter \shared_buffer\ change in configuration file
ignored),
errdetail(This parameter cannot be changed after server start.)
Seems a bit awkwardly phrased. I propose
errmsg(attempted change to parameter \shared_buffer\ ignored),
errdetail(This parameter cannot be changed after server start.)
(or possibly of would read better than to)
'of' sounds better than 'to'.
Best regards,
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
Mail sent from my BlackLaptop device
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.55
diff -c -c -r1.55 guc-file.l
*** src/backend/utils/misc/guc-file.l 9 May 2008 15:36:31 - 1.55
--- src/backend/utils/misc/guc-file.l 22 Aug 2008 00:01:00 -
***
*** 258,265
{
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(parameter \%s\ cannot be changed after server start; configuration file change ignored,
! gconf-name)));
continue;
}
--- 258,266
{
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(attempted change of parameter \%s\ ignored,
! gconf-name),
! errdetail(This parameter cannot be changed after server start.)));
continue;
}
Index: src/backend/utils/misc/guc.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.466
diff -c -c -r1.466 guc.c
*** src/backend/utils/misc/guc.c 15 Aug 2008 08:37:40 - 1.466
--- src/backend/utils/misc/guc.c 22 Aug 2008 00:01:06 -
***
*** 4598,4613
if (changeVal !is_newvalue_equal(record, value))
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(parameter \%s\ cannot be changed after server start; configuration file change ignored,
! name)));
return true;
}
if (context != PGC_POSTMASTER)
{
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(parameter \%s\ cannot be changed after server start,
! name)));
return false;
}
break;
--- 4598,4615
if (changeVal !is_newvalue_equal(record, value))
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(attempted change of parameter \%s\ ignored,
! name),
! errdetail(This parameter cannot be changed after server start.)));
return true;
}
if (context != PGC_POSTMASTER)
{
ereport(elevel,
(errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(attempted change of parameter \%s\ ignored,
! name),
! errdetail(This parameter cannot be changed after server start.)));
return false;
}
break;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
Alvaro Herrera escribió: They did not merge with the text, but they were not searchable. May I suggest using the text [easy] and [done] instead? That way, it is searchable, and they don't merge with the text. I just made this change. What I now notice is that both markers are visually not very different. I don't know if this is something worth fussing about. (Maybe the addition of icons as Brendan was suggesting would be sufficient visual clue.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: patch to create explicit support for semi and anti joins
Kevin Grittner [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] wrote: Introduce JOIN_SEMI and JOIN_ANTI join types, the former replacing JOIN_IN. It just struck me that this may cause additional joins to count against the join_collapse_limit. If so, that could cause some borderline queries to optimize poorly if the limit isn't raised. Is that a reasonable concern? Possibly something to document in the release notes? I don't think we should change anything there. The collapse limit settings are mainly driven by not wanting to get into an exponential growth of planning time, and the way in which join situations are created doesn't really affect the appropriate value one way or the other. In a case where this did happen, you'd just have exchanged one suboptimal planning situation for another, so I'm unconvinced that it'd make matters any worse compared to prior releases. (That does seem like a point worth testing, though, if you want to.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new border setting in psql
D'Arcy J.M. Cain [EMAIL PROTECTED] writes: On Thu, 21 Aug 2008 23:22:28 +0300 Asko Oja [EMAIL PROTECTED] wrote: The idea would be to use psql as backend for some other system? Or what do you mean by fed directly? No, I meant that one would do any ad hoc query and cut and paste the output directly into a tracking tool that supports ReST. There's still the question of whether this covers any needs that aren't met just as well by XML or CSV output formats. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki
Bruce Momjian [EMAIL PROTECTED] writes: The TODO link on the developer page needs to be updated too: http://www.postgresql.org/developer/ Also, is this page still sane? http://wiki.postgresql.org/wiki/Todo:Contents If it is, I suggest it be renamed to TodoDetail or some such. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing
Bruce Momjian [EMAIL PROTECTED] writes: Added to TODO: Eliminate de-TOASTing of values when not needed That's a fairly bad description of what the patch was about. I changed it to Reduce costs of repeat de-TOASTing of values regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Difference when using ZIC vs. Timezone Abbr - Bug?
Dave Witt [EMAIL PROTECTED] writes: These two queries produce different output, using version 8.3.3: SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'MDT'; SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'America/Boise'; Why are you surprised? Boise would've been on MST not MDT on that date. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [pgsql-www] [HACKERS] [FINALLY] the TODO list has migrated to Wiki
Alvaro Herrera [EMAIL PROTECTED] writes: Alvaro Herrera escribió: They did not merge with the text, but they were not searchable. May I suggest using the text [easy] and [done] instead? That way, it is searchable, and they don't merge with the text. I just made this change. What I now notice is that both markers are visually not very different. I don't know if this is something worth fussing about. Perhaps [Easy] and [Done] would look a little more different? Not sure. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new border setting in psql
On Thu, 21 Aug 2008 20:36:51 -0400 Tom Lane [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain [EMAIL PROTECTED] writes: No, I meant that one would do any ad hoc query and cut and paste the output directly into a tracking tool that supports ReST. There's still the question of whether this covers any needs that aren't met just as well by XML or CSV output formats. Well, we could remove all the display formats except XML. After all, it can always be converted to any other format. Of course we wouldn't do that. User convenience is all I'm thinking of. What do you think of the idea of allowing user defined display functions? Of course, that's a much bigger job. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
Alvaro Herrera wrote: Alvaro Herrera escribi?: They did not merge with the text, but they were not searchable. May I suggest using the text [easy] and [done] instead? That way, it is searchable, and they don't merge with the text. I just made this change. What I now notice is that both markers are visually not very different. I don't know if this is something worth fussing about. (Maybe the addition of icons as Brendan was suggesting would be sufficient visual clue.) Looks OK. The only downside is that reading down the list now has the easy/done items shifted to the left, but that seems unavoidable. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Difference when using ZIC vs. Timezone Abbr - Bug?
Tom Lane wrote: Dave Witt [EMAIL PROTECTED] writes: These two queries produce different output, using version 8.3.3: SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'MDT'; SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'America/Boise'; Why are you surprised? Boise would've been on MST not MDT on that date. i.e. try using MST7MDT instead, which behaves more sanely. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new border setting in psql
Tom Lane escribió: D'Arcy J.M. Cain [EMAIL PROTECTED] writes: On Thu, 21 Aug 2008 23:22:28 +0300 Asko Oja [EMAIL PROTECTED] wrote: The idea would be to use psql as backend for some other system? Or what do you mean by fed directly? No, I meant that one would do any ad hoc query and cut and paste the output directly into a tracking tool that supports ReST. There's still the question of whether this covers any needs that aren't met just as well by XML or CSV output formats. I think it does -- I used to use the Latex output format for easy cut'n pasting. ReST sounds like it serves the same purpose. If I had had to use conversion to XML, it would have been rather painful. What I wonder is whether this should be a border setting or a format setting. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should enum GUCs be listed as such in config.sgml?
Tom Lane wrote: Currently, config.sgml still describes the new enum GUC variables as being of type string --- but pg_settings says they are enum. This is not very consistent, but I wonder whether changing the docs would be more confusing or less so. I note that section 18.1 doesn't mention the enum alternative either. I looked into this and I think the documentation is fine. If enums didn't require quotes but strings did, we would document them differently, but the fact is that enums are the same as strings except enums have a limited number of possible values --- that isn't something that is usually identified in a variable type definition heading. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Does anything dump per-database config settings? (was Re: [HACKERS] ALTER DATABASE vs pg_dump)
On Thursday 21 August 2008 18:28:55 Bruce Momjian wrote:
We never came up with any idea of how pg_dump could dump ALTER DATABASE
... SET commands, so I have added a mention in the documentation, and
backpatched to 8.3.X; attached.
ok, I have no recollection of this conversation :-)
but...
! The dump file also does not
!contain any commandALTER DATABASE ... SET/ commands;
!these settings are dumped by xref linkend=app-pg-dumpall,
!along with database users and other installation-wide settings.
/para
Is misleading (or maybe just wrong) because those settings are not dumped with
the other installation wide settings. Meaning that pg_dumpall -g has no
bearing on the alter database commands being set, you actually have to
dumpall the entire data set to get those lines.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should enum GUCs be listed as such in config.sgml?
bruce wrote: Tom Lane wrote: Currently, config.sgml still describes the new enum GUC variables as being of type string --- but pg_settings says they are enum. This is not very consistent, but I wonder whether changing the docs would be more confusing or less so. I note that section 18.1 doesn't mention the enum alternative either. I looked into this and I think the documentation is fine. If enums didn't require quotes but strings did, we would document them differently, but the fact is that enums are the same as strings except enums have a limited number of possible values --- that isn't something that is usually identified in a variable type definition heading. Looking further, it seems we still have an inconsistency problem because pg_settings mentions enum; should we just change that to 'string'? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Does anything dump per-database config settings? (was Re: [HACKERS] ALTER DATABASE vs pg_dump)
Robert Treat wrote: On Thursday 21 August 2008 18:28:55 Bruce Momjian wrote: We never came up with any idea of how pg_dump could dump ALTER DATABASE ... SET commands, so I have added a mention in the documentation, and backpatched to 8.3.X; attached. ok, I have no recollection of this conversation :-) but... ! The dump file also does not !contain any commandALTER DATABASE ... SET/ commands; !these settings are dumped by xref linkend=app-pg-dumpall, !along with database users and other installation-wide settings. /para Is misleading (or maybe just wrong) because those settings are not dumped with the other installation wide settings. Meaning that pg_dumpall -g has no bearing on the alter database commands being set, you actually have to dumpall the entire data set to get those lines. Oh, that is odd, but documented: -g --globals-only Dump only global objects (roles and tablespaces), no databases. ALTER DATABASE ... SET seems to be something that doesn't fit in anywhere; I am thinking pg_dump -g should dump it. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Does anything dump per-database config settings? (was Re: [HACKERS] ALTER DATABASE vs pg_dump)
Bruce Momjian [EMAIL PROTECTED] writes: ALTER DATABASE ... SET seems to be something that doesn't fit in anywhere; I am thinking pg_dump -g should dump it. The upthread conclusion was that pg_dump -C should do it. I am not sure how you come to the conclusion that -g is an appropriate place, seeing that -g will not create the database(s) that it'd be trying to apply ALTER to. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: new border setting in psql
On Thu, 21 Aug 2008 21:19:58 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: Tom Lane escribió: There's still the question of whether this covers any needs that aren't met just as well by XML or CSV output formats. I think it does -- I used to use the Latex output format for easy cut'n pasting. ReST sounds like it serves the same purpose. If I had had to use conversion to XML, it would have been rather painful. ReST is nice because it's almost plain text. In fact, a ReST document source can easily be read raw. What I wonder is whether this should be a border setting or a format setting. I don't see it as a format for two reasons. First, it isn't really a different format. It's just the same format as border 2 with a few extra lines. Second, and following from the first, it's such a logical progression from border 0 to the proposed border 3 that that syntax makes more sense. In fact, the guide is inches away from describing this behaviour already. Besides, making it a border option adds 12 lines to the code, 5 of which are blank. I wouldn't want to think about the changes if it was a different setting. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal sql: labeled function params
2008/8/21 Asko Oja [EMAIL PROTECTED]: Would AS be harder to implement? select foo(10 AS a, 20 AS b); select foo(20 AS b, 20 AS a); select x(0 = 1 AS a); other fantasies select foo(10 a, 20 b); select foo(a 10, b 20); no, I have it. Problem is in semantic. There are two features, that fight about this keyword - named params and labeled params. I don't thing so using AS for named params is good idea - mainly it's out of standard (if I should count with SQL/XML) and out of tradition. regards Pavel p.s. = is clean and readable, I thing it's better than space syntax :) regards, Asko On Wed, Aug 20, 2008 at 4:26 PM, Pavel Stehule [EMAIL PROTECTED] wrote: 2008/8/20 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: I understand now why Oracle use = symbol for named params. This isn't used so operator - so implementation is trivial. You really didn't understand the objection at all, did you? The point is not about whether there is any built-in operator named =. The point is that people might have created user-defined operators named that. I understand well, so only I don't see better solution. Yes, everyone who used = should have problems, but it is similar with .. new keywords, etc. Probably easy best syntax doesn't exist :(. I haven't idea who use = now and how often, and if this feature is possible in pg, but there are not technical barriers. regards Pavel Stehule regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About a message when pg_ctl -w start failed
Hi, thanks for your reply. Tom Lane wrote: If a user who perform pg_ctl -w start does not have authority to connect postgres-database, pg_ctl will return 1 and show could not start server message. You didn't say what auth method you are using The problem that I showed occurs in following case for example. 1. user_1$ initdb -D /tmp/test 2. user_1$ sudo chown -R user_2:user_2 /tmp/test 3. user_2$ pg_ctl -D /tmp/test -w start -- problem occurs! (Because, there is no role for user_2 in /tmp/test. But server starting.) I'd think the right fix is to make it recognize other types of authentication failures as well. Yes, I agree. I think role and database(postgres) existence check is necessary before starting postmaster. # Or improve the connection test way in test_postmaster_connection(). Best regards, -- Tatsuhito Kasahara [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
