Re: [HACKERS] Bogus TODO item

2008-08-21 Thread Asko Oja
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

2008-08-21 Thread Zdenek Kotala

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

2008-08-21 Thread Peter Eisentraut
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

2008-08-21 Thread alexander lunyov

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

2008-08-21 Thread Alvaro Herrera
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

2008-08-21 Thread Tatsuhito Kasahara
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

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread Peter Eisentraut
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

2008-08-21 Thread D'Arcy J.M. Cain
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

2008-08-21 Thread Peter Eisentraut
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

2008-08-21 Thread Alvaro Herrera
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

2008-08-21 Thread Alvaro Herrera
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

2008-08-21 Thread Markus Wanner

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

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread Kevin Grittner
 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

2008-08-21 Thread D'Arcy J.M. Cain
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

2008-08-21 Thread Asko Oja
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

2008-08-21 Thread Alvaro Herrera
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

2008-08-21 Thread Asko Oja
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

2008-08-21 Thread Bruce Momjian
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

2008-08-21 Thread D'Arcy J.M. Cain
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

2008-08-21 Thread Bruce Momjian

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

2008-08-21 Thread Alvaro Herrera
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?

2008-08-21 Thread Dave Witt

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

2008-08-21 Thread Albert Cervera i Areny
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)

2008-08-21 Thread Bruce Momjian

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

2008-08-21 Thread Bruce Momjian

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

2008-08-21 Thread Bruce Momjian
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

2008-08-21 Thread Albert Cervera i Areny
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

2008-08-21 Thread Bruce Momjian
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

2008-08-21 Thread Alvaro Herrera
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

2008-08-21 Thread Bruce Momjian

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

2008-08-21 Thread Alvaro Herrera
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

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread Tom Lane
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?

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread D'Arcy J.M. Cain
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

2008-08-21 Thread Bruce Momjian
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?

2008-08-21 Thread Alvaro Herrera
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

2008-08-21 Thread Alvaro Herrera
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?

2008-08-21 Thread Bruce Momjian
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)

2008-08-21 Thread Robert Treat
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?

2008-08-21 Thread Bruce Momjian
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)

2008-08-21 Thread Bruce Momjian
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)

2008-08-21 Thread Tom Lane
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

2008-08-21 Thread D'Arcy J.M. Cain
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-08-21 Thread Pavel Stehule
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

2008-08-21 Thread Tatsuhito Kasahara
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