date:20090328

 Jaime == Jaime Casanova jcasa...@systemguards.com.ec writes:

 Jaime In the TODO list there is an item [D] Completed itemAdd
 Jaime array_agg() and UNNEST functions for arrays  marked as done
 Jaime but 5 items below there is: Add SQL-standard array_agg() and
 Jaime unnest() array functions  it's the same item so this one
 Jaime should be removed... or there is a difference between the
 Jaime array_agg() and unnest() implemented versus SQL-standard
 Jaime array_agg() and unnest()?

The array_agg() does, I believe, match the standard one, at least
my reading of the spec doesn't reveal any obvious issues there.

The unnest() implementation is largely unrelated to the standard one,
which is impossible to provide without LATERAL.

-- 
Andrew (irc:RhodiumToad)

-- 
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] PQinitSSL broken in some use casesf

2009-03-28 Thread Merlin Moncure

On Fri, Mar 27, 2009 at 9:38 PM, Bruce Momjian br...@momjian.us wrote:
 I have applied the attached patch which does several things:

        o  documents that libssl _and_ libcrypto initialization is
           turned off by PQinitSSL(0)
        o  clarified cases where this behavior is important
        o  added comments that the CRYPTO_set_* calls reference
           libcrypto, not libssl

 I think we can now say that the current behavior is not a bug because it
 is documented, even though the PQinitSSL() function name is inaccurate.

It is still a bug in the sense that it is impossible to properly
initialize crypto features in some scenarios.  A doc patch (which I
argued is the best way to go for 8.4) fails to properly raise the
seriousness of the issue and also fails to suggest a workaround.

I think a proper way to document this issue would be something like this:


If your application initializes libcrypto, but not libssl, you must
not call PQinitSSL(1) because it will overwrite your libcrypto
initialization.  In order to safely use libpq in your application, you
must include ssl headers and call the following functions:

#include openssl/ssl.h
#include openssl/conf.h

OPENSSL_config(NULL);
SSL_library_init();
SSL_load_error_strings();
PQinitSSL(0);

In order to initialize libpq properly for SSL connections.


 I think there is a good argument that PQinitSSL(X) where X  1 would
 work fine for more fine-grained control.  The new libpq init function
 idea was interesting, but having a documented solution for
 WSAStartup()/WSACleanup() usage, we now don't have another libpq init
 use-case so it is hard to suggest a new libpq function.

This feature when discussed at the time was not enough _by itself_ to
support a PQinit feature (I agree with this reasoning), but surely
should be considered as valid supporting evidence that a library
initialization feature is useful.  IOW, the whole of the argument is
equal to the sum of its parts.   (yes, we have an agenda here: we were
not happy that our events patch could not establish behavior at
library initialization time).

merlin

-- 
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] PQinitSSL broken in some use casesf

2009-03-28 Thread Merlin Moncure

On Sat, Mar 28, 2009 at 9:23 AM, Merlin Moncure mmonc...@gmail.com wrote:
 It is still a bug in the sense that it is impossible to properly
 initialize crypto features in some scenarios.  A doc patch (which I

Meant to say: 'your doc patch

merlin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] question about deparsing const node and its typmod

2009-03-28 Thread Tao Ma

Hi,

Recently, I am reading the postgres codes, and I have a question about the
deparsing some expressions which is contains Const node. The following SQL
will retrieve the definition stored by postgres database for table t:

CREATE TABLE t (c1 CHAR(5) DEFAULT 'abc',
  c2 CHAR(5) DEFAULT 'abc'::CHAR(5));

SELECT pg_get_expr(adbin, adrelid)
FROM pg_attrdef
WHERE adrelid = (SELECT oid FROM pg_class WHERE relname = 't');

 pg_get_expr
-
 'abc'::bpchar
 'abc'::character(5)
(2 rows)

Postgres will emit a implicit coercion for the default value of c1 column
before the definition node can be stored in system catalog pg_attrdef.
To retrieve a human-readable definition for the default value, pg_get_expr()
will call get_func_expr() to display the default value. get_func_expr()
will omit the implicit function and return the first argument barely. The
default value for column c2 is pretty than the default value for column c1,
so I am courious about is there any possibility to make the default value
for c1 look like the default value for c2.

If we do not concern the compatible with old system, is it possible to
modify the function transformExpr() or something else to archieve the the
'pretty'(may be not pretty at all for someone) format? It seems assign the
correct typmod to Const node during transform phase is possible, but most
of time it is meaningless. typmod plays an important role during the
process of coercion decision, it seems the coercion will absence iff the
type and typmod is same.

Thanks in advance,
Tao Ma




-- 
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] TODO item

Andrew Gierth wrote:
  Jaime == Jaime Casanova jcasa...@systemguards.com.ec writes:
 
  Jaime In the TODO list there is an item [D] Completed itemAdd
  Jaime array_agg() and UNNEST functions for arrays  marked as done
  Jaime but 5 items below there is: Add SQL-standard array_agg() and
  Jaime unnest() array functions  it's the same item so this one
  Jaime should be removed... or there is a difference between the
  Jaime array_agg() and unnest() implemented versus SQL-standard
  Jaime array_agg() and unnest()?
 
 The array_agg() does, I believe, match the standard one, at least
 my reading of the spec doesn't reveal any obvious issues there.
 
 The unnest() implementation is largely unrelated to the standard one,
 which is impossible to provide without LATERAL.

I removed the duplicate item;  we can add more details about what
additional functionality we need once we get user feedback.

-- 
  Bruce Momjian  br...@momjian.ushttp://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] Should SET ROLE inherit config params?

Simon Riggs wrote:
 
 On Fri, 2009-03-27 at 23:25 -0400, Bruce Momjian wrote:
  Josh Berkus wrote:
   
Josh, this isn't a rejection. Both Tom and I asked for more exploration
of the implications of doing as you suggest. Tom has been more helpful
than I was in providing some scenarios that would cause problems. It is
up to you to solve the problems, which is often possible. 
   
   OK, well, barring the context issues, what do people think of the idea?
   
   What I was thinking was that this would be a setting on the SET ROLE 
   statement, such as:
   
   SET ROLE special WITH SETTINGS
   
   ... or similar; I'd need to find an existing keyword which works.
   
   I think this bypasses a lot of the issues which Tom raises, but I'd want 
   to think about the various permutations some more.
  
  I have added the following TODO:
  
  Allow role-specific ALTER ROLE SET variable settings to be processed
  independently of login; SET ROLE does not process role-specific variable
  settings
  
  * 
  http://archives.postgresql.org/message-id/49b82cd7.20...@agliodbs.com 
  
  and the attached patch which better documents our current behavior.
 
 I don't think there is an agreed todo item there. We were in the middle
 of discussing other ideas and this is the wrong time to have a longer
 debate on the topic. We should not squash other ideas by putting this as
 a todo item yet.

Since when does a TODO item squash ideas?  I didn't chisel the TODO item
in stone;  if there is more discussion, someone can update the TODO
item.  Leaving stuff dangle around undocumented is the wrong approach. 
As it is the TODO items is vague.

-- 
  Bruce Momjian  br...@momjian.ushttp://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] 8.4 release notes proof reading 1/2

David E. Wheeler wrote:
 On Mar 27, 2009, at 6:40 PM, Bruce Momjian wrote:
 
  Thanks, text updated:
 
While semi-joins merely replace existing IN joins, anti-joins
are a new capability for NOT EXISTS clauses (Tom) This improves
optimization possibilities.
 
 I'm not enough of a relational algebra geek to really understand what  
 that means. Will there be a link or something to some documentation or  
 even, *gasp*, a blog entry explaining what this means and why it's  
 important?

Uh, not really;  the optimizer stuff is usually quite vague and Tom
might end update removing it once he goes over the release note anyway
(he has in the past).  I documented it because it is a user-visible
change,  I think, becuase it might show up in EXPLAIN.

-- 
  Bruce Momjian  br...@momjian.ushttp://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] Crash in gist insertion on pathological box data

 Martijn == Martijn van Oosterhout klep...@svana.org writes:

  The nature of the problem is this: if gist_box_picksplit doesn't
  find a good disposition on the first try, then it tries to split
  the data again based on the positions of the box centers. But
  there's a problem here with floating-point rounding; it's possible
  for the average of N floating-point values to be strictly greater
  (or less) than all of the values individually, and the function
  then returns with, for example, all the entries assigned to the
  left node, and nothing in the right node. This causes gistSplit to
  try and split the left node again, with predictable results.

 Martijn ISTM the simplest solution here is detect that everything
 Martijn has been put in one node (left or right) and in that case
 Martijn just split the list straight down the middle (since clearly
 Martijn it doesn't matter on which side they appear.).

It's not quite so simple; we know that not all the values are equal,
since that's checked for earlier in the code (if they're all actually
equal they just get split down the middle). In this specific case the
values could actually be quite different, since we're only looking
at the centers; and with, say, a large number of very different size
boxes all centered on the same point, it would be preferable to split
them so that at least one node has a smaller union.

I'm interested to see what Oleg's solution (see other thread) is.

-- 
Andrew.

-- 
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] TODO item

 Bruce == Bruce Momjian br...@momjian.us writes:

  The unnest() implementation is largely unrelated to the standard
  one, which is impossible to provide without LATERAL.

 Bruce I removed the duplicate item; we can add more details about
 Bruce what additional functionality we need once we get user
 Bruce feedback.

The missing functionality from the spec is:

1) select ... from foo, unnest(foo.bar);   -- UNNEST is implicitly LATERAL

2) multiple arrays:  select * from unnest(a,b);

3) expansion of composite arrays: unnest(a) should return as many
columns as there are in the elements of a, not just one composite
column

4) WITH ORDINALITY - adds a column to the result with the array index

It's point (1) that's the killer - without it, unnest() is just a
trivial shorthand for stuff that can be done anyway; it doesn't
actually add any functionality.

-- 
Andrew.

-- 
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] TODO item

Andrew Gierth wrote:
  Bruce == Bruce Momjian br...@momjian.us writes:
 
   The unnest() implementation is largely unrelated to the standard
   one, which is impossible to provide without LATERAL.
 
  Bruce I removed the duplicate item; we can add more details about
  Bruce what additional functionality we need once we get user
  Bruce feedback.
 
 The missing functionality from the spec is:
 
 1) select ... from foo, unnest(foo.bar);   -- UNNEST is implicitly LATERAL
 
 2) multiple arrays:  select * from unnest(a,b);
 
 3) expansion of composite arrays: unnest(a) should return as many
 columns as there are in the elements of a, not just one composite
 column
 
 4) WITH ORDINALITY - adds a column to the result with the array index
 
 It's point (1) that's the killer - without it, unnest() is just a
 trivial shorthand for stuff that can be done anyway; it doesn't
 actually add any functionality.

OK, so what should the TODO wording be?

-- 
  Bruce Momjian  br...@momjian.ushttp://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] TODO item

2009-03-28 Thread Jeff Davis

On Sat, 2009-03-28 at 11:57 +, Andrew Gierth wrote:
 The array_agg() does, I believe, match the standard one, at least
 my reading of the spec doesn't reveal any obvious issues there.

I think it's missing the ORDER BY clause. This is not as important for
PostgreSQL because we can do ORDER BY in a subselect, but it's still a
deviation from the standard.

Regards,
Jeff Davis


-- 
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] TODO item

 Jeff == Jeff Davis pg...@j-davis.com writes:

  On Sat, 2009-03-28 at 11:57 +, Andrew Gierth wrote:
  The array_agg() does, I believe, match the standard one, at least
  my reading of the spec doesn't reveal any obvious issues there.

 Jeff I think it's missing the ORDER BY clause.

Hm, yeah, so it is.

Could that be added (not for 8.4, and not necessarily just for
array_agg but for all aggregates) by piggybacking on the existing
DISTINCT mechanism for aggregates?

-- 
Andrew.

-- 
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] TODO item

 Bruce == Bruce Momjian br...@momjian.us writes:

  1) select ... from foo, unnest(foo.bar);   -- UNNEST is implicitly LATERAL
 [...]
  It's point (1) that's the killer - without it, unnest() is just a
  trivial shorthand for stuff that can be done anyway; it doesn't
  actually add any functionality.

 Bruce OK, so what should the TODO wording be?

Under SQL Commands:

 * implement LATERAL (and corresponding UNNEST functionality)

(LATERAL is, I suspect, a fairly big project because of the amount of
planner work involved, but it's also a fairly high-value project
because (a) it's useful (we usually get a couple of cases every week
on the IRC chan where people ask how do I do X, where X would be
trivial with LATERAL but requires complex and often inefficient SQL
without it), and (b) it potentially presents optimization
opportunities even for queries that don't use it.)

-- 
Andrew.

-- 
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] 8.4 open items list

On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 and the first two items from the questions category, which
 don't seem important enough to worry about at this stage of the game.

 Both of those things are related to 8.4 feature changes, so we should
 either do them now or decide we won't do them.

Well, Should we have a LOCALE option in CREATE DATABASE? has to do
with making:

CREATE DATABASE foo WITH LOCALE = bar
equivalent to...
CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar

That might be nice to have, but since it's just syntactic sugar, I
disagree that it's now or never.

The second item, Should we reject toast.fillfactor in reloptions?,
comes with a patch.  I think I agree with ITAGAKI Takahiro that it
would be better to have reloptions specify a set of RELOPT_KINDs to
which they pertain rather than a single one.  There are likely to be
other types of reloptions that could apply to more than one category
of objects, and duplicating the definitions is not a desirable coping
strategy.  So I guess I'm in favor of applying this patch if others
are satisfied with the quality of the code (which I have looked at,
but only briefly).  Given the fact that anyone who understands both
toast and fillfactor should know that they don't make sense together
(and we can also document this), I don't think too many people will
get bitten if we ignored this issue for 8.4 and then applied the patch
to 8.5, but since the code is already written, there may be no reason
to take the risk.

...Robert

-- 
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] 8.4 open items list

Robert Haas robertmh...@gmail.com writes:
 On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Both of those things are related to 8.4 feature changes, so we should
 either do them now or decide we won't do them.

 Well, Should we have a LOCALE option in CREATE DATABASE? has to do
 with making:

 CREATE DATABASE foo WITH LOCALE = bar
 equivalent to...
 CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar

 That might be nice to have, but since it's just syntactic sugar, I
 disagree that it's now or never.

The reason I wanted it considered now is that part of the discussion
was about whether to rename the existing options (add or remove LC_,
I forget which).  Once 8.4 is out it'll be too late to reconsider that.

 The second item, Should we reject toast.fillfactor in reloptions?,
 comes with a patch.  I think I agree with ITAGAKI Takahiro that it
 would be better to have reloptions specify a set of RELOPT_KINDs to
 which they pertain rather than a single one.

+1.  And this is something it'd be better to get right now than later,
since it's about an API that's meant to be used by add-on modules.

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] question about deparsing const node and its typmod

Tao Ma feng_e...@163.com writes:
 CREATE TABLE t (c1 CHAR(5) DEFAULT 'abc',
   c2 CHAR(5) DEFAULT 'abc'::CHAR(5));

 SELECT pg_get_expr(adbin, adrelid)
 FROM pg_attrdef
 WHERE adrelid = (SELECT oid FROM pg_class WHERE relname = 't');

  pg_get_expr
 -
  'abc'::bpchar
  'abc'::character(5)
 (2 rows)

 so I am courious about is there any possibility to make the default value
 for c1 look like the default value for c2.

That behavior is very carefully chosen to reproduce the actual semantics
of the expression in various contexts.  We can't change it just to make
it look prettier.

If you check the CVS history of ruleutils.c to see when that logic got
changed, you should be able to locate pgsql-hackers discussions that
worked out what the behavior has to be.  I seem to remember that the
most recent iteration had to do with making sure that ALTER COLUMN TYPE
had unsurprising side-effects on the column's default.

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] [COMMITTERS] pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks

Bruce Momjian br...@momjian.us writes:
 Tom, you mentioned this should be a TODO item.  Do we put it on our main
 TODO, and if so, in what section?

Optimizer/executor I guess.  It's a pretty vague TODO though.  We need
some way to consider alternative join orders for joins that do not
semantically commute.  When I wrote that CVS log entry I was thinking
in terms of fixing the executor so that the joins actually could
commute, which would involve some way of separating the
force-vars-to-null behavior of an outer join from the actual execution
of the join.  I don't know how practical that really is though (and
also I've got a feeling it likely would fall foul of some patent or
other).  Or maybe it could be solved entirely in the planner, but I
don't have an idea of what the planner's internal representation would
have to look like to do that.

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] pg_migrator progress

Bruce Momjian br...@momjian.us writes:
 Tom Lane wrote:
 But having said that, there isn't any real harm in fixing the OID
 counter to match what it was.  You need to run pg_resetxlog to set the
 WAL position and XID counter anyway, and it can set the OID counter too.

 FYI, I decided against restoring the oid counter because it might
 collide with an oid assigned during pg_migrator schema creation.

That argument seems pretty empty --- why is it more likely than a
collision happening if you *don't* restore the oid counter?  And why
would it matter anyway?  We fixed the problems with oid collisions
some time ago.

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] tuplestore API problem

Hitoshi Harada umi.tan...@gmail.com writes:
 So I tried pass EState.es_tupleTables to tuplestore_begin_heap() to
 trace those TupleTableSlots. Note that if you pass NULL the behavior
 is as before so nothing's broken. Regression passes but I'm not quite
 sure EState.es_tupleTable is only place that holds TupleTableSlots
 passed to tuplestore...

I've got zero confidence in that, and it seems pretty horrid from a
system structural point of view even if it worked: neither tuplestore.c
nor its direct callers have any business knowing where all the slots
are.  What might be a bit saner is to remember the slot last passed to
tuplestore_gettupleslot for each read pointer.  The implication would be
that we'd be assuming only one slot is used to fetch from any one read
pointer, but that is probably a reasonable restriction.

 I know you propose should_copy boolean parameter would be added to
 tuplestore_gettupleslot().

I already did it, and concluded that not only were all the
tuplestore_gettupleslot calls in nodeWindowAgg broken, but so was
nodeCtescan.  I'm open to reverting that patch if you have a better
solution though.

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] 8.4 open items list

2009-03-28 Thread Dave Page

On Sat, Mar 28, 2009 at 4:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Both of those things are related to 8.4 feature changes, so we should
 either do them now or decide we won't do them.

 Well, Should we have a LOCALE option in CREATE DATABASE? has to do
 with making:

 CREATE DATABASE foo WITH LOCALE = bar
 equivalent to...
 CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar

 That might be nice to have, but since it's just syntactic sugar, I
 disagree that it's now or never.

 The reason I wanted it considered now is that part of the discussion
 was about whether to rename the existing options (add or remove LC_,
 I forget which).  Once 8.4 is out it'll be too late to reconsider that.

Please bear in mind that whilst these features have been going into
Postgres over the last 12 months, other people have been busy adding
support for them in tools and interfaces etc. so changing anything
even before we go to beta should not be done on a whim. This is even
worse than might be immediately apparent because we generally need to
get our code stable *before* PostgreSQL is released to ensure that
tools and interfaces are definitely ready in time - for example,
pgAdmin is already in it's second beta.

-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.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] Solaris getopt_long and PostgreSQL

I wrote:
After reviewing this thread and the one that led up to the 8.3 behavior,
it seems clear that we failed to draw a distinction between getopt and
getopt_long when we should have. We don't like Solaris' getopt but
there seems no reason not to use Solaris' getopt_long. So Zdenek's
suggestion to change configure seems the correct fix, and I've done
that.

So my reward for that is to find that every one of the Solaris 11
buildfarm members is failing today:

pg_regress: initdb failed
Examine
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.6320/src/test/regress/log/initdb.log
for the reason.
Command was:
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.6320/src/test/regress/./tmp_check/install//export/home/tmp/pg-test/build-suncc/HEAD/inst/bin/initdb
-D
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.6320/src/test/regress/./tmp_check/data
-L
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.6320/src/test/regress/./tmp_check/install//export/home/tmp/pg-test/build-suncc/HEAD/inst/share/postgresql
--noclean --no-locale
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.6320/src/test/regress/log/initdb.log
21
make: *** [check] Error 2

== pgsql.6320/src/test/regress/log/initdb.log
===
initdb: too many command-line arguments (first is -L)
Try initdb --help for more information.
Running in noclean mode. Mistakes will not be cleaned up.

Apparently the system version of getopt_long is broken on Solaris 11.
My patience for this grows short.

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] TODO item

2009-03-28 Thread Jeff Davis

On Sat, 2009-03-28 at 15:35 +, Andrew Gierth wrote:
  Jeff == Jeff Davis pg...@j-davis.com writes:
 
   On Sat, 2009-03-28 at 11:57 +, Andrew Gierth wrote:
   The array_agg() does, I believe, match the standard one, at least
   my reading of the spec doesn't reveal any obvious issues there.
 
  Jeff I think it's missing the ORDER BY clause.
 
 Hm, yeah, so it is.
 
 Could that be added (not for 8.4, and not necessarily just for
 array_agg but for all aggregates) by piggybacking on the existing
 DISTINCT mechanism for aggregates?

I'm sure it's possible, but it seems like a significant amount of work.
I don't feel very strongly about it myself, because, as I said, it can
be worked around using an ORDER BY in a subselect.

Regards,
Jeff Davis


-- 
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 SET ROLE inherit config params?

2009-03-28 Thread Josh Berkus


Bruce, Simon,


I don't think there is an agreed todo item there. We were in the middle
of discussing other ideas and this is the wrong time to have a longer
debate on the topic. We should not squash other ideas by putting this as
a todo item yet.


I agree.  We don't have consensus on the TODO.   We need to hash it out 
more after 8.4 goes beta.


--Josh


--
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] psql \d* and system objects

2009-03-28 Thread Euler Taveira de Oliveira

Bruce Momjian escreveu:
 The psql system object display issue has not been completely resolved
 for 8.4;  see 8.4 open items:
 
   http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
 
 So what is the proposal?  Have U/S/A flags for all commands and have
 different system display default for each command?
 
[I don't read the whole thread but...] Why don't we use a DISPLAY_OBJECTS psql
variable? The point in providing metacommands is facility. If we're using a
psql variable, we don't need to add another character to distinguish between
system, user, or both. Also, I don't think people frequently change the search
class (system, user, or both) so I don't buy the argument that it is more
easier to type another letter each time than typing a '\set FOO bar' once per
dozens of commands.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.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] PQinitSSL broken in some use casesf

Merlin Moncure wrote:
 It is still a bug in the sense that it is impossible to properly
 initialize crypto features in some scenarios.  A doc patch (which I
 argued is the best way to go for 8.4) fails to properly raise the
 seriousness of the issue and also fails to suggest a workaround.
 
 I think a proper way to document this issue would be something like this:
 
 
 If your application initializes libcrypto, but not libssl, you must
 not call PQinitSSL(1) because it will overwrite your libcrypto
 initialization.  In order to safely use libpq in your application, you
 must include ssl headers and call the following functions:
 
   #include openssl/ssl.h
   #include openssl/conf.h
 
   OPENSSL_config(NULL);
   SSL_library_init();
   SSL_load_error_strings();
   PQinitSSL(0);
 
 In order to initialize libpq properly for SSL connections.
 
 
  I think there is a good argument that PQinitSSL(X) where X  1 would
  work fine for more fine-grained control. ?The new libpq init function
  idea was interesting, but having a documented solution for
  WSAStartup()/WSACleanup() usage, we now don't have another libpq init
  use-case so it is hard to suggest a new libpq function.
 
 This feature when discussed at the time was not enough _by itself_ to
 support a PQinit feature (I agree with this reasoning), but surely
 should be considered as valid supporting evidence that a library
 initialization feature is useful.  IOW, the whole of the argument is
 equal to the sum of its parts.   (yes, we have an agenda here: we were
 not happy that our events patch could not establish behavior at
 library initialization time).

Well, we are not the Make Merlin Happy club.  ;-)

Making usable software requires adjustments on everyone's part.  I don't
think we have enough demand to hardcode those details in our
documentation.

Personally, I feel adding #defines for PQinitSSL is the right approach,
and I think that gives enough checks at compile time, but it doesn't
guard against cases where the application is built against one version
of libpq but is run against an older version, which I think can happen.

My personal opinion is that adding #defines to PQinitSSL() is the right
level of fix, and if we ever implement a libpq init mechanism we can
convert PGinitSSL to a macro. I am attaching a sample patch for
feedback. 

However, as I mentioned above, this is not the Make Bruce Happy club
either so I need support from other developers that this is the right
fix.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/libpq.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.280
diff -c -c -r1.280 libpq.sgml
*** doc/src/sgml/libpq.sgml	28 Mar 2009 01:36:11 -	1.280
--- doc/src/sgml/libpq.sgml	28 Mar 2009 19:06:45 -
***
*** 6172,6181 
 If your application initializes literallibssl/ or
 literallibcrypto/ libraries and applicationlibpq/application
 is built with acronymSSL/ support, you should call
!functionPQinitSSL(0)/ to tell applicationlibpq/application
 that the literallibssl/ and literallibcrypto/ libraries
 have been initialized by your application so
 applicationlibpq/application will not initialize those libraries.
 !-- If this URL changes replace it with a URL to www.archive.org. --
 See ulink
 url=http://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.html;/ulink
--- 6172,6185 
 If your application initializes literallibssl/ or
 literallibcrypto/ libraries and applicationlibpq/application
 is built with acronymSSL/ support, you should call
!functionPQinitSSL(PG_NO_INIT_SSL_CRYPTO)/ to tell applicationlibpq/application
 that the literallibssl/ and literallibcrypto/ libraries
 have been initialized by your application so
 applicationlibpq/application will not initialize those libraries.
+To have applicationlibpq/application initialize only
+literallibssl/, use functionPQinitSSL(PG_INIT_SSL_ONLY)/, and
+use functionPQinitSSL(PG_INIT_CRYPTO_ONLY)/ to initialize only
+literallibcrypto/.
 !-- If this URL changes replace it with a URL to www.archive.org. --
 See ulink
 url=http://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.html;/ulink
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.121
diff -c -c -r1.121 fe-secure.c
*** src/interfaces/libpq/fe-secure.c	28 Mar 2009 18:48:55 -	1.121
--- src/interfaces/libpq/fe-secure.c	28 Mar 2009 19:06:45 -
***
*** 99,104 
--- 99,105 
  static void SSLerrfree(char *buf);
  
  static bool pq_init_ssl_lib = true;
+ static bool

Re: [HACKERS] pg_migrator progress

Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  Tom Lane wrote:
  But having said that, there isn't any real harm in fixing the OID
  counter to match what it was.  You need to run pg_resetxlog to set the
  WAL position and XID counter anyway, and it can set the OID counter too.
 
  FYI, I decided against restoring the oid counter because it might
  collide with an oid assigned during pg_migrator schema creation.
 
 That argument seems pretty empty --- why is it more likely than a
 collision happening if you *don't* restore the oid counter?  And why

We don't transfer any system-level oids so there is no chance of a
collision against system tables.

 would it matter anyway?  We fixed the problems with oid collisions
 some time ago.

Oh, we handled that;  OK, old code restored.

-- 
  Bruce Momjian  br...@momjian.ushttp://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

[HACKERS] Re: [COMMITTERS] pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks

Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  Tom, you mentioned this should be a TODO item.  Do we put it on our main
  TODO, and if so, in what section?
 
 Optimizer/executor I guess.  It's a pretty vague TODO though.  We need
 some way to consider alternative join orders for joins that do not
 semantically commute.  When I wrote that CVS log entry I was thinking
 in terms of fixing the executor so that the joins actually could
 commute, which would involve some way of separating the
 force-vars-to-null behavior of an outer join from the actual execution
 of the join.  I don't know how practical that really is though (and
 also I've got a feeling it likely would fall foul of some patent or
 other).  Or maybe it could be solved entirely in the planner, but I
 don't have an idea of what the planner's internal representation would
 have to look like to do that.

Yea, this is beyond the detail we normally put in the TODO list.  If we
want to add this I am afraid we will need to document other optimizer
items as well.

-- 
  Bruce Momjian  br...@momjian.ushttp://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] Should SET ROLE inherit config params?

Josh Berkus wrote:
 Bruce, Simon,
 
  I don't think there is an agreed todo item there. We were in the middle
  of discussing other ideas and this is the wrong time to have a longer
  debate on the topic. We should not squash other ideas by putting this as
  a todo item yet.
 
 I agree.  We don't have consensus on the TODO.   We need to hash it out 
 more after 8.4 goes beta.

OK, I am confused, but item removed.  :-|

-- 
  Bruce Momjian  br...@momjian.ushttp://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] PQinitSSL broken in some use casesf

Bruce Momjian br...@momjian.us writes:
 Well, we are not the Make Merlin Happy club.  ;-)

Merlin and Andrew were the ones complaining initially.  If they feel
that a proposed patch doesn't fix the problem, then I'd say that it
isn't fixing the problem.

 My personal opinion is that adding #defines to PQinitSSL() is the right
 level of fix, and if we ever implement a libpq init mechanism we can
 convert PGinitSSL to a macro. I am attaching a sample patch for
 feedback. 

This is just a rehash of one of the patches that was discussed earlier.
There wasn't consensus for it then, and there's not now.

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] PQinitSSL broken in some use casesf

2009-03-28 Thread Andrew Chernow


Tom Lane wrote:

This is just a rehash of one of the patches that was discussed earlier.
There wasn't consensus for it then, and there's not now.



I am personally out of ideas.  It feels like this issue has been beaten 
to death.  There are only a few ways to do it and I believe they have 
all been put on the table.  Any suggestions?


--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.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] psql \d* and system objects

Euler Taveira de Oliveira wrote:
 Bruce Momjian escreveu:
  The psql system object display issue has not been completely resolved
  for 8.4;  see 8.4 open items:
  
  http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
  
  So what is the proposal?  Have U/S/A flags for all commands and have
  different system display default for each command?
  
 [I don't read the whole thread but...] Why don't we use a DISPLAY_OBJECTS psql
 variable? The point in providing metacommands is facility. If we're using a
 psql variable, we don't need to add another character to distinguish between
 system, user, or both. Also, I don't think people frequently change the search
 class (system, user, or both) so I don't buy the argument that it is more
 easier to type another letter each time than typing a '\set FOO bar' once per
 dozens of commands.

I think the problem is that people often use \dt and then \df or \dT,
and odds are they would want different system-visible behavior for
those.  I think we could have a setting that would choose a default of
'user-only', or 'all', but I still think we would need the ability to
override it at command time.

-- 
  Bruce Momjian  br...@momjian.ushttp://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] PQinitSSL broken in some use casesf

Andrew Chernow wrote:
 Tom Lane wrote:
  This is just a rehash of one of the patches that was discussed earlier.
  There wasn't consensus for it then, and there's not now.
  
 
 I am personally out of ideas.  It feels like this issue has been beaten 
 to death.  There are only a few ways to do it and I believe they have 
 all been put on the table.  Any suggestions?

Well, at least the current behavior is documented now.  I personally
thought the #define was the best minimal fix because it only added a few
lines to the docs and the C code.

-- 
  Bruce Momjian  br...@momjian.ushttp://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] PQinitSSL broken in some use casesf

2009-03-28 Thread Merlin Moncure

On Sat, Mar 28, 2009 at 4:26 PM, Bruce Momjian br...@momjian.us wrote:
 Andrew Chernow wrote:
 Tom Lane wrote:
  This is just a rehash of one of the patches that was discussed earlier.
  There wasn't consensus for it then, and there's not now.
 

 I am personally out of ideas.  It feels like this issue has been beaten
 to death.  There are only a few ways to do it and I believe they have
 all been put on the table.  Any suggestions?

 Well, at least the current behavior is documented now.

You mean, with your proposed documentation patch?  (if you meant my
proposed advice, then ignore the following paragraph)

Not only does it not suggest the problem, it actually misinforms
you...it suggests you call PQinitSSL(0) when your application
initializes literallibssl/ or  literallibcrypto/ libraries.
The operative word being 'or'.  If you follow the advice after only
having initialized the libcrypto library, you would get a failure
trying to use libpq/SSL.

merlin

-- 
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] improving concurrent transactin commit rate

2009-03-28 Thread Dimitri Fontaine


Hi,

Le 27 mars 09 à 21:42, Sam Mason a écrit :

OK, that's turned out to be a good point.  I've now written five
different versions and they don't seem to give the results I'm  
expecting

at all!


If you're that much willing to have a good concurrent load simulator  
client for postgresql, my take is for you to test tsung. This surely  
will take less time than rewriting it with result I'd suspect less  
efficient than the 20+ years of research that came into Erlang design  
and implementation :)

  http://tsung.erlang-projects.org/
  http://archives.postgresql.org/pgsql-admin/2008-12/msg00032.php

Your task will be to install erlang and tsung, then to write up a load  
parameter XML script embedding your SQL requests as CDATA. You could  
define more than one session and ask to mix what session each  
simulated user will run (70% of this, 20% of that, 10% of the latter),  
and give a thinktime between some requests, will get be respected on  
average (with a grain of randomness).


Have fun,
--
dim
--
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] 8.4 release notes proof reading 1/2

Guillaume Smet wrote:
 On Fri, Mar 27, 2009 at 2:44 AM, Bruce Momjian br...@momjian.us wrote:
  Guillaume Smet wrote:
  - Add -M (query mode) to /contrib/pgbench (ITAGAKI Takahiro)
  -Itagaki san's name inconsistent with other mentions of his name
 
  Above all fixed, thanks.
 
 I think you fixed this one the wrong way.
 
 It should be s/ITAGAKI Takahiro/Takahiro Itagaki/g, shouldn't it?

Based on mentions of his name in previous release notes, you are
correct;  change committed.

-- 
  Bruce Momjian  br...@momjian.ushttp://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] Unsupported effective_io_concurrency platforms

Tom Lane wrote:
 Peter Eisentraut pete...@gmx.net writes:
  Joshua D. Drake wrote:
  Do we want to give a more informative error message, like not supported
  on this platform?
 
  The trick will be to fit this into the GUC framework.
 
 You could do it by enforcing the limit in an assign hook, but I'm
 not convinced it's worth the trouble.

I have created a patch to at least display a more helpful message,
without being specific:

test= set effective_io_concurrency = 1;
ERROR:  parameter effective_io_concurrency cannot be changed from 0

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: src/backend/utils/misc/guc.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.497
diff -c -c -r1.497 guc.c
*** src/backend/utils/misc/guc.c9 Mar 2009 14:34:34 -   1.497
--- src/backend/utils/misc/guc.c28 Mar 2009 23:40:52 -
***
*** 4738,4747 
}
if (newval  conf-min || newval  
conf-max)
{
!   ereport(elevel,
!   
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!errmsg(%d is 
outside the valid range for parameter \%s\ (%d .. %d),
!   
newval, name, conf-min, conf-max)));
return false;
}
}
--- 4738,4753 
}
if (newval  conf-min || newval  
conf-max)
{
!   if (conf-min == conf-max)
!   ereport(elevel,
!   
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!
errmsg(parameter \%s\ cannot be changed from %d,
!   
name, conf-min)));
!   else
!   ereport(elevel,
!   
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!
errmsg(%d is outside the valid range for parameter \%s\ (%d .. %d),
!   
newval, name, conf-min, conf-max)));
return false;
}
}
***
*** 4810,4819 
}
if (newval  conf-min || newval  
conf-max)
{
!   ereport(elevel,
!   
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!errmsg(%g is 
outside the valid range for parameter \%s\ (%g .. %g),
!   
newval, name, conf-min, conf-max)));
return false;
}
}
--- 4816,4831 
}
if (newval  conf-min || newval  
conf-max)
{
!   if (conf-min == conf-max)
!   ereport(elevel,
!   
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!
errmsg(parameter \%s\ cannot be changed from %g,
!   
name, conf-min)));
!   else
!   ereport(elevel,
!   
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!
errmsg(%g is outside the valid range

Re: [HACKERS] PQinitSSL broken in some use casesf

On Sat, Mar 28, 2009 at 3:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Bruce Momjian br...@momjian.us writes:
 Well, we are not the Make Merlin Happy club.  ;-)

 Merlin and Andrew were the ones complaining initially.  If they feel
 that a proposed patch doesn't fix the problem, then I'd say that it
 isn't fixing the problem.

+1.

 My personal opinion is that adding #defines to PQinitSSL() is the right
 level of fix, and if we ever implement a libpq init mechanism we can
 convert PGinitSSL to a macro. I am attaching a sample patch for
 feedback.

 This is just a rehash of one of the patches that was discussed earlier.
 There wasn't consensus for it then, and there's not now.

OK, I read this patch.  Wazzamatterwithit?

AIUI, we need to define an API that allows libssl and libcrypto to be
initialized or not initialized in any combination.  We can do this by
modifying the meaning of the argument to PQinitSSL(), by adding a new
API function, by creating some more general initialization function,
or by some other method.  It doesn't REALLY matter.  I think I'm
personally of the opinion that PQinitSSL(int) should be left alone and
we should define PQinitSSLCrypto(int, int), just to avoid the
possibility of difficult-to-debug backward-compatibility problems, but
the number of people calling PQinitSSL(2) in existing applications is
doubtless vanishingly small, because there is probably no reason to
call it with a non-constant argument, so who is going to pick 2 rather
than 1?  So if someone has some sort of principled objection to adding
a new API call, then let's just modify the behavior of the existing
call instead and move on.

Is there more substance here than meets the eye?

...Robert

-- 
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] psql \d* and system objects

On Sat, Mar 28, 2009 at 1:25 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
 Bruce Momjian escreveu:
 The psql system object display issue has not been completely resolved
 for 8.4;  see 8.4 open items:

       http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes

 So what is the proposal?  Have U/S/A flags for all commands and have
 different system display default for each command?

 [I don't read the whole thread but...] Why don't we use a DISPLAY_OBJECTS psql
 variable? The point in providing metacommands is facility. If we're using a
 psql variable, we don't need to add another character to distinguish between
 system, user, or both. Also, I don't think people frequently change the search
 class (system, user, or both) so I don't buy the argument that it is more
 easier to type another letter each time than typing a '\set FOO bar' once per
 dozens of commands.

I think you should reconsider your non-buying of that argument.  That
would be really, really annoying for me.  Most of the time I want to
look at a user object.  But every now and then I want to look at a
system object.  Having to type two commands to get that would be
completely annoying.

...Robert

-- 
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] psql \d* and system objects

On Sat, Mar 28, 2009 at 4:25 PM, Bruce Momjian br...@momjian.us wrote:
 Euler Taveira de Oliveira wrote:
 Bruce Momjian escreveu:
  The psql system object display issue has not been completely resolved
  for 8.4;  see 8.4 open items:
 
      http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
 
  So what is the proposal?  Have U/S/A flags for all commands and have
  different system display default for each command?
 
 [I don't read the whole thread but...] Why don't we use a DISPLAY_OBJECTS 
 psql
 variable? The point in providing metacommands is facility. If we're using a
 psql variable, we don't need to add another character to distinguish between
 system, user, or both. Also, I don't think people frequently change the 
 search
 class (system, user, or both) so I don't buy the argument that it is more
 easier to type another letter each time than typing a '\set FOO bar' once per
 dozens of commands.

 I think the problem is that people often use \dt and then \df or \dT,
 and odds are they would want different system-visible behavior for
 those.  I think we could have a setting that would choose a default of
 'user-only', or 'all', but I still think we would need the ability to
 override it at command time.

Yeah, I like this.  I think we could even make it a little more
fine-tuned.  For example you might have an option whose values is a
list of object types for which system tables are excluded by default,
with * meaning all.  So you could have:

tsv = exclude system tables, sequences, and views by default
tsvf = exclude system tables, sequences, views, and functions by default
* = don't show any system objects by default
empty string = show all system objects by default

I don't really care about the details, just suggesting it would be
useful to be able to tune by object type.

...Robert

-- 
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] PQinitSSL broken in some use casesf

2009-03-28 Thread Andrew Chernow


Robert Haas wrote:


Is there more substance here than meets the eye?



No, you about summed it up.  We need a way to init libssl and libcrypto 
in any combo.  Along the way, PQinit() was discussed which may have 
muddied the waters.


I prefer leaving the PQinitSSL function alone, thus my patch that 
implements PQinitSecure(flags).


Adding PQinitSSL(new_value) seem reasonable to me.  My only complaint 
has been that the API user has no way of knowing if the function 
understood their request.  An older libpq would treat any non-zero 
argument as one, which would silently fail/mis-behave from a new apps 
perspective.  Not sure this can be solved.


In the end, anyway you do it will have an issue or two.  I agree that it 
really doesn't matter, all methods would probably do the trick.


Andrew Chernow
eSilo, LLC

--
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] PQinitSSL broken in some use casesf