date:20060712


Hi Dave,
Sorry I missed you at the Summit. I would've liked to discuss PL/J 
versus PL/Java with you.


What is the status of PL/J? I haven't seen much activity there over the 
last 10 months. Does it run on Windows yet? Are you planning a first 
release anytime soon? Do you have any active users? Does the project 
still have over 40 dependencies to other components? The last time I 
looked (August last year) a beta-0.1.1 was planned. I didn't manage to 
built it and it didn't seem anywhere close production readiness.


Perhaps it's no surprise that I disagree when you say PL/J could be 
considered in the same light as PL/Java. Then again, I'm fairly biased ;-)


Regards,
Thomas Hallgren


Dave Cramer wrote:

Absolutely PL/J should be considered in the same light as PL/Java.

Consider this a request for PL/J to be included in the core.

Dave
On 11-Jul-06, at 12:50 PM, Josh Berkus wrote:


David,


It's good to integrate things with the core as needed.  What plans do
we have to integrate PL/J?


None, if the PL/J team doesn't speak up.  So far I have yet to see a 
request for PL/J or even a release notice.


--Josh

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings






---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread Peter Eisentraut

Am Dienstag, 11. Juli 2006 17:40 schrieb Alvaro Herrera:
 We've discussed this before, regarding PL/php IIRC.  The conclusions the
 last time around, as far as I remember, was that we wanted the PLs to be
 in the same CVS repo, but able to be compiled separately from the whole
 source tree.

That was precisely what I recall.  But if we make them separate CVS modules, 
they would not have the same branch structure, or would they?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [PATCHES] [HACKERS] kerberos related warning

2006-07-12 Thread Peter Eisentraut

Am Mittwoch, 12. Juli 2006 04:38 schrieb Joe Conway:
  gcc -O -Wall -Wmissing-prototypes -Wpointer-arith -Winline
  -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g
  -pthread  -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic
  -DFRONTEND -I. -I../../../src/include -D_GNU_SOURCE  -I/usr/include/et
  -I../../../src/port  -c -o fe-auth.o fe-auth.c -MMD
  fe-auth.c: In function 'pg_fe_getauthname':
  fe-auth.c:573: warning: passing argument 1 of 'free' discards qualifiers
  from pointer target type

I don't see that.  Which Kerberos version do you have?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 6: explain analyze is your friend

[HACKERS] pg_dump and inherits issue

2006-07-12 Thread Jim Buttafuoco

I have an issue with pg_dump and inherits with pg 8.1.3 and 8.1.4

if I run the following SQL
create table t (a text check (a = '*'));
create table s () inherits (t);
alter table s drop constraint t_a_check;
alter table s add constraint a_check check (a='s');

I get the following
 Table public.t
 Column | Type | Modifiers 
+--+---
 a  | text | 
Check constraints:
t_a_check CHECK (a = '*'::text)

 Table public.s
 Column | Type | Modifiers 
+--+---
 a  | text | 
Check constraints:
a_check CHECK (a = 's'::text)
Inherits: t

and then create a new database and run
pg_dump old_db |psql new_db

I get the following
 Table public.t
 Column | Type | Modifiers 
+--+---
 a  | text | 
Check constraints:
t_a_check CHECK (a = '*'::text)

 Table public.s
 Column | Type | Modifiers 
+--+---
 a  | text | 
Check constraints:
a_check CHECK (a = 's'::text)
t_a_check CHECK (a = '*'::text)
Inherits: t

The check constraints on table s are not like the original, I have an extra 
t_a_check constraint.  Is this correct?

Jim

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[HACKERS] Updateable views for 8.2 or 8.3?

2006-07-12 Thread Jaime Casanova


Hi,

is anybody working on the Bernd Helmle's updateable views patch? or
know what the status of this is?

--
regards,
Jaime Casanova

Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning.
  Richard Cook

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Implied Functional Index use

2006-07-12 Thread Peter Eisentraut

Am Dienstag, 11. Juli 2006 23:31 schrieb Tom Lane:
 We could invent some more-complex concept involving well, this is
 equality, but there are some functions for which f(x) might differ
 from f(y) anyway and then mark the presumably-few functions that
 could produce divergent results --- examples are sgn() for float8
 and anything dependent on dscale for numeric.  This seems ugly and
 error prone however.

From a mathematical point of view, it seems cleaner to attach this property to 
functions, not operators, namely, this function preserves the following 
relations.  This would allow extending Simon's idea to other operators such 
as  and  and possibly more mind-boggling cases with geometric operators and 
such.

Admittedly, this would put a lot of additional typing load on function 
authors, but perhaps it's safer that way.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread Hannu Krosing

Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen:
  There should be a Procedural Language section on pgfoundry for all of the
  PLs, IMHO, and a README in contrib within core that points to it
  (README.procedural_languages, if nothing else) ...
 
 I thought that the general consensus was that only plpgsql ought to be in 
 core, the rest should be independent projects.

That would be doable if we had a stable language API.

As i understand it, we still dont. And even more - most of the changes
to API come frome the needs of those (new) languages 

 It would be nice to have an easy way to retrieve and install the desired PL's 
 but that's more of a packaging issue.
 
-- 

Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com



---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [PATCHES] [HACKERS] kerberos related warning

2006-07-12 Thread Joe Conway


Peter Eisentraut wrote:

Am Mittwoch, 12. Juli 2006 04:38 schrieb Joe Conway:


gcc -O -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g
-pthread  -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic
-DFRONTEND -I. -I../../../src/include -D_GNU_SOURCE  -I/usr/include/et
-I../../../src/port  -c -o fe-auth.o fe-auth.c -MMD
fe-auth.c: In function 'pg_fe_getauthname':
fe-auth.c:573: warning: passing argument 1 of 'free' discards qualifiers
from pointer target type



I don't see that.  Which Kerberos version do you have?


I don't think it's related to Kerberos except that the entire problem is 
 #ifdef'd out unless configure --with-krb5 is used. Maybe more 
related to gcc version? In any case, I'm running stock fedora core 5:


krb5-libs-1.4.3-4.1
gcc-4.1.1-1.fc5

Joe

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread Andrew Dunstan


Hannu Krosing wrote:

Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen:
  

There should be a Procedural Language section on pgfoundry for all of the
PLs, IMHO, and a README in contrib within core that points to it
(README.procedural_languages, if nothing else) ...
  
I thought that the general consensus was that only plpgsql ought to be in 
core, the rest should be independent projects.



That would be doable if we had a stable language API.

As i understand it, we still dont. And even more - most of the changes
to API come frome the needs of those (new) languages 

  


There is in effect no API at all, other than what is available to all 
backend modules. If someone wants to create an API which will be both 
sufficiently stable and sufficiently complete to meet the needs of the 
various PLs (especially, as Hannu rightly observes, any new PLs that 
come along) then  we can revisit this question. Until then I suggest 
that it is at best premature. I am not even sure such a thing is 
actually possible.


Also there is this: speaking as someone who actually does some work in 
this area, I very much appreciate having the eagle eyes of people like 
Tom, Neil and Joe on what's going on, and keeping things on the straight 
and narrow. I at least would feel lots less comfortable about 
maintaining things without such help.


The Postgres hacker community is small. I am not sure there is an 
adequate pool of people who will maintain the momentum of each 
sub-project that we might choose to orphan. If we had thousands of eager 
code cutters it might be different, but we don't, really.


cheers

andrew



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread David Fetter

On Wed, Jul 12, 2006 at 07:29:52AM -0700, Joshua D. Drake wrote:
 On Wednesday 12 July 2006 04:15, Dave Cramer wrote:
  Absolutely PL/J should be considered in the same light as PL/Java.
 
  Consider this a request for PL/J to be included in the core.
 
 Frankly I don't care which one is used, as long as the one (and ONLY one) 
 that 
 is included is the most mature and stable.

Are they mutually exclusive?  I can imagine, at least for development
purposes, that someone might want to install both.

Cheers,
D
 
 Sincerely,
 
 Joshua D. Drake
 
 
  Dave
 
  On 11-Jul-06, at 12:50 PM, Josh Berkus wrote:
   David,
  
   It's good to integrate things with the core as needed.  What plans do
   we have to integrate PL/J?
  
   None, if the PL/J team doesn't speak up.  So far I have yet to see
   a request for PL/J or even a release notice.
  
   --Josh
  
   ---(end of
   broadcast)---
   TIP 5: don't forget to increase your free space map settings
 
  ---(end of broadcast)---
  TIP 6: explain analyze is your friend
 
 -- 
=== The PostgreSQL Company: Command Prompt, Inc. ===
 Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
  http://www.commandprompt.com/
 

-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
  Skype: davidfetter

Remember to vote!

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Three weeks left until feature freeze

On Wednesday 12 July 2006 04:15, Dave Cramer wrote:
 Absolutely PL/J should be considered in the same light as PL/Java.

 Consider this a request for PL/J to be included in the core.

Frankly I don't care which one is used, as long as the one (and ONLY one) that 
is included is the most mature and stable.

Sincerely,

Joshua D. Drake


 Dave

 On 11-Jul-06, at 12:50 PM, Josh Berkus wrote:
  David,
 
  It's good to integrate things with the core as needed.  What plans do
  we have to integrate PL/J?
 
  None, if the PL/J team doesn't speak up.  So far I have yet to see
  a request for PL/J or even a release notice.
 
  --Josh
 
  ---(end of
  broadcast)---
  TIP 5: don't forget to increase your free space map settings

 ---(end of broadcast)---
 TIP 6: explain analyze is your friend

-- 
   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread Jonah H. Harris


On 7/12/06, David Fetter [EMAIL PROTECTED] wrote:

Are they mutually exclusive?  I can imagine, at least for development
purposes, that someone might want to install both.


I believe both can be installed and running at the same time.  I don't
really think anyone would want to run both, but that's just my
opinion.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED]
Iselin, New Jersey 08830| http://www.enterprisedb.com/

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] lastval exposes information that currval does not

2006-07-12 Thread Bruce Momjian


Updated text:

   For schemas, allows access to objects contained in the specified
   schema (assuming that the objects' own privilege requirements are
   also met).  Essentially this allows the grantee to quotelook up/
   objects within the schema.  Without this permission, it is still
   possible to see the object names by querying the system tables, but
   they cannot be accessed via SQL.


---

Jan Wieck wrote:
 On 7/9/2006 8:32 AM, Martijn van Oosterhout wrote:
 
  On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote:
  On Jul 6, 2006, at 11:02 AM, Phil Frost wrote:
  I hope the above example is strong enough to elicit a comment from a
  qualified developer. If it is not, consider that stored procedures
  contain prepared statements, and many client applications cache  
  prepared
  statements as well. Thus, revoking usage on a schema is about as  
  good as
  nothing until all sessions have ended. It also means that any function
  which operates with OIDs can potentially bypass the schema usage  
  check.
  
  The docs probably should elaborate that once something's been looked  
  up you no longer need permissions on the schema it resides in.
  
  I'm not sure this is really unexpected behaviour. On UNIX it is clearly
  defined that file permissions are checked only on open. Once you've
  opened it, changing permissions on the file won't affect you. If
  someone passes you a read/write descriptor to a file, you can
  read/write it even if you didn't have permissions to open the
  file/socket/whatever yourself.
 
 This isn't the case and I do agree with Phil on this. The fact that 
 another security definer function did access an object during the 
 session should not give the user the ability to access it in the manner 
 shown in his example. lastval() without arguments should not remember 
 the sequence by its oid only, but also remember the sequences schema and 
 to a proper ACL check on that as well.
 
 Just think of it if SELECT without a FROM clause would automatically 
 assume the same rangetable as the last SELECT in the session. If that 
 were the case, would you guy's defend the position that SELECT * then 
 should spit out the full content of the last table accessed by the 
 security definer function just called, even if the user doesn't have 
 schema permission? I doubt!
 
 
 Jan
 
  
  I'm not sure it makes sense to be able to revoke someone's permissions
  on an object they've already accessed. From a transactional point of
  view, the revoke should at the very least not affect transactions
  started prior to the revokation. Some things are shared across an
  entire session, and the rule extends to them. Is this a bug? Maybe, but
  it is debatable.
  
  Have a nice day,
 
 
 -- 
 #==#
 # It's easier to get forgiveness for being wrong than for being right. #
 # Let's break this rule - forgive me.  #
 #== [EMAIL PROTECTED] #
 
 ---(end of broadcast)---
 TIP 6: explain analyze is your friend

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Three weeks left until feature freeze

Andrew Dunstan wrote:
There is in effect no API at all, other than what is available to all
backend modules. If someone wants to create an API which will be both
sufficiently stable and sufficiently complete to meet the needs of the
various PLs (especially, as Hannu rightly observes, any new PLs that
come along) then we can revisit this question. Until then I suggest
that it is at best premature. I am not even sure such a thing is
actually possible.

I concur with this. The needs for a module like PL/Java is very different then the needs of
PL/Perl so let's get some more PL's in before we do a refactoring effort to create common
API's. Personally, I'm not sure what would be included. The call handler API's together with
the SPI API's are in essence what you need. The rest is fairly specialized anyway.

Also there is this: speaking as someone who actually does some work in
this area, I very much appreciate having the eagle eyes of people like
Tom, Neil and Joe on what's going on, and keeping things on the straight
and narrow. I at least would feel lots less comfortable about
maintaining things without such help.

This is partly why I'd like to get PL/Java included. Not that I expect any of them to devote
resources to PL/Java but I think that they, from time to time, will visit the code. If not
for anything else then to see why some other change caused build failures. It's always
easier to have discussions around code that you know they all have on disk.

The Postgres hacker community is small. I am not sure there is an
adequate pool of people who will maintain the momentum of each
sub-project that we might choose to orphan. If we had thousands of eager
code cutters it might be different, but we don't, really.

As the project grows for various reasons, the number of hackers in the community will grow
as well. PL/Java for instance, does not come without resources :-)

Regards,
Thomas Hallgren

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

[HACKERS] Online index builds

2006-07-12 Thread Greg Stark


I just sent in the patch for online index builds to -patches.

. The work to combine the two phases into a single non-transactional command
  is done. I'm not sure how long to wait between lock checks or how verbose to
  be about why it's taking so long. I do think we have to print something or
  else the DBA won't know if it's hung waiting for something external.
  Currently it prints a notice the first time it sleeps. 

. Also it prints out how many tuples it found which normal index doesn't.
  Probably that message should go away. On the other hand the index stats
  probably need to be filled in.

. I need to check what locks I'm taking. I think I still have some old code
  with the wrong locks in it.

. this includes the tid btree opclass sent earlier (with a warning I didn't
  notice before fixed up). opr_sanity now fails but I think that's due to the
  gin commits not this opclass.

. In case of an error during phase2 the invalid index is left in place. It can
  be dropped with DROP INDEX. The footwork to get it dropped in case of an
  error would be quite tricky but there's a sketch of how to do it in the 
source.

. no documentation yet, there's not much to write though.

. no regression tests yet. I don't see any way to test this reasonably in the
  regression tests. I've done some testing myself by building indexes while
  pgbench is running. Then I have to do index scans to see how many records
  are returned with index scans. It wouldn't be easy to automate and even if
  it were done it wouldn't really be all that great a test. The corner cases
  found during the development are pretty narrow and will be hard to reliably
  test.

-- 
greg


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread Jonah H. Harris


On 7/12/06, Thomas Hallgren [EMAIL PROTECTED] wrote:

it didn't seem anywhere close production readiness.

Perhaps it's no surprise that I disagree when you say PL/J could be
considered in the same light as PL/Java.


Having used both systems, I have to agree with Thomas; PL/Java is far
ahead of PL/J in terms of production readiness.  Rather than argue the
differences between the architectures... I think it should be looked
at on a pro/con basis.

Many people have asked for procedural Java and generally pass over
PostgreSQL because they don't know about PL/Java or PL/J.  In my
opinion, having a Java PL included in the core would be ideal.

PL/Java seems to be the only Java PL under consistent development and
maintenance, so I don't see it as something that would fall on the
shoulders of all other maintainers.

Just my 2 cents :)

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED]
Iselin, New Jersey 08830| http://www.enterprisedb.com/

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread elein

On Wed, Jul 12, 2006 at 10:14:53AM -0400, Andrew Dunstan wrote:
 Hannu Krosing wrote:
 Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen:
   
 There should be a Procedural Language section on pgfoundry for all of the
 PLs, IMHO, and a README in contrib within core that points to it
 (README.procedural_languages, if nothing else) ...
   
 I thought that the general consensus was that only plpgsql ought to be in 
 core, the rest should be independent projects.
 
 
 That would be doable if we had a stable language API.
 
 As i understand it, we still dont. And even more - most of the changes
 to API come frome the needs of those (new) languages 
 
   
 
 There is in effect no API at all, other than what is available to all 
 backend modules. If someone wants to create an API which will be both 
 sufficiently stable and sufficiently complete to meet the needs of the 
 various PLs (especially, as Hannu rightly observes, any new PLs that 
 come along) then  we can revisit this question. Until then I suggest 
 that it is at best premature. I am not even sure such a thing is 
 actually possible.
 
 Also there is this: speaking as someone who actually does some work in 
 this area, I very much appreciate having the eagle eyes of people like 
 Tom, Neil and Joe on what's going on, and keeping things on the straight 
 and narrow. I at least would feel lots less comfortable about 
 maintaining things without such help.


If I've caught the right threads... Informix IUS and Illustra had a language
manager module which facilitated function resolution and argument marshalling
ala SQL and then made the calls to each language in the same API/function
call format.  Usually I do not like added layers, however, this layer could
and should be used to deal with function resolution, type coercion, domains,
etc, which is the SQL side.  The language itself would have predefined ways
of getting arguments and returning data.  I'm not sure if this approach
would work with the bonus extras on plpgsql, but it should.

If anyone wants to pursue this area, please include me on the discussion
and I can try to provide information regarding the other implementation.  

--elein

 
 The Postgres hacker community is small. I am not sure there is an 
 adequate pool of people who will maintain the momentum of each 
 sub-project that we might choose to orphan. If we had thousands of eager 
 code cutters it might be different, but we don't, really.
 
 cheers
 
 andrew
 
 
 
 ---(end of broadcast)---
 TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly
 

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Updateable views for 8.2 or 8.3?

2006-07-12 Thread Joe Conway


Jaime Casanova wrote:


is anybody working on the Bernd Helmle's updateable views patch? or
know what the status of this is?


I was just wondering about this also. If no one else is working on it, 
I'd like to try to push it through to completion for 8.2 myself. Can 
anyone summarize what the open issues are?


Joe

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] Three weeks left until feature freeze


 I concur with this. The needs for a module like PL/Java is very different
 then the needs of PL/Perl so let's get some more PL's in before we do a
 refactoring effort to create common API's. Personally, I'm not sure what
 would be included. The call handler API's together with the SPI API's are
 in essence what you need. The rest is fairly specialized anyway.

Well I know it isn't an API per say, but one interesting tid bit as an example 
is that PLphp does not need the PostgreSQL source to compile. It only needs 
pgxs and the relevant headers etc...

Perhaps that is one way to go... All PLs use pgxs?

 As the project grows for various reasons, the number of hackers in the
 community will grow as well. PL/Java for instance, does not come without
 resources :-)

We have already grown for hackers quite a bit this year as they mature I think 
we will see even more patch review eyes and such... Soon.

Sincerely,

Joshua D. Drake




 Regards,
 Thomas Hallgren


 ---(end of broadcast)---
 TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

-- 
   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Three weeks left until feature freeze


Joshua D. Drake wrote:


Well I know it isn't an API per say, but one interesting tid bit as an example 
is that PLphp does not need the PostgreSQL source to compile. It only needs 
pgxs and the relevant headers etc...


Perhaps that is one way to go... All PLs use pgxs?

  
PL/Java does. No source needed. So yes, there's already a fairly good 
API that assists in the module build process. It does however still 
include all header files needed by the backend and thus, leaves the 
backend wide open (in a matter of speech). If a refactoring effort was 
to start later on, that would be a good place to start. I.e. divide 
headers into the ones available for external modules and the ones for 
internal backend use only.


Regards,
Thomas Hallgren


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] lastval exposes information that currval does not

2006-07-12 Thread Phil Frost

On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote:
 
 Updated text:
 
For schemas, allows access to objects contained in the specified
schema (assuming that the objects' own privilege requirements are
also met).  Essentially this allows the grantee to quotelook up/
objects within the schema.  Without this permission, it is still
possible to see the object names by querying the system tables, but
they cannot be accessed via SQL.

No, this still misses the point entirely. See all my examples in this
thread for ways I have accessed objects without usage to their schema
with SQL.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] pg_dump and inherits issue

2006-07-12 Thread Greg Stark

Jim Buttafuoco [EMAIL PROTECTED] writes:

 The check constraints on table s are not like the original, I have an extra
 t_a_check constraint. Is this correct?

I wouldn't say it's correct but it is known.

I think the plan is to have such constraints be marked so you *can't* drop
them as long as you're a child of another table that has them. But Postgres
doesn't yet track where constraints came from or check that you don't drop
ones that are inherited.

-- 
greg


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Online index builds

2006-07-12 Thread Simon Riggs

On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote:
 no regression tests yet.

We'll need some performance tests that show that lock-hold time is
*actually* reduced, given the shenanigans needed to get there.

We may need to have usage recommendations in the docs.

-- 
  Simon Riggs
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Implied Functional Index use

2006-07-12 Thread Simon Riggs

On Tue, 2006-07-11 at 17:31 -0400, Tom Lane wrote:
 Simon Riggs [EMAIL PROTECTED] writes:
  ...
  - add a new boolean to pg_operator to allow us to define which operators
  offer true equality
  ...
 
 This would be useful for other purposes too, as we keep coming up
 against what's the equality operator for this datatype problems.
 However, the restriction to true equality, such that we can assume
 x = y implies f(x) = f(y) for every immutable function f on the datatype
 (note this need not necessarily mean bitwise equality --- it depends on
 what operations the datatype provides), seems like a problem.  For
 instance, the ordinary = operators on float and numeric are NOT true
 equality, nor do we provide any true equality in this sense for these
 common datatypes.  We could hardly get away with using this concept
 to drive foreign-key comparisons, if it doesn't work for float or
 numeric.

Normally, I would not suggest that we do things only for certain data
types only. In this case however, it seems that the reason it would work
only for INTEGER and TEXT data types is that they are simple atomic
datatypes that have the required properties. So doing this for those
datatypes only seems permissable on a theoretical basis, rather than
just because we can't be bothered to do it for more complex types.

-- 
  Simon Riggs
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] lastval exposes information that currval does not

2006-07-12 Thread Bruce Momjian

Phil Frost wrote:
 On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote:
  
  Updated text:
  
 For schemas, allows access to objects contained in the specified
 schema (assuming that the objects' own privilege requirements are
 also met).  Essentially this allows the grantee to quotelook up/
 objects within the schema.  Without this permission, it is still
 possible to see the object names by querying the system tables, but
 they cannot be accessed via SQL.
 
 No, this still misses the point entirely. See all my examples in this
 thread for ways I have accessed objects without usage to their schema
 with SQL.

OK, well we are not putting a huge paragraph in there.  Please suggest
updated text.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] pre_load_libraries

2006-07-12 Thread Marc Munro

On Wed, 2006-07-12 at 02:18 -0300, I wrote:
 I am trying to create an initialisation function that is called using
 the  preload_libraries option.
 
 The purpose of this is to set up shared memory for Veil, independant
 of postgres' own shared memory.  Simple init functions work fine, but
 as soon as I place calls to ShemAlloc, or LWLockAssign, the server
 startup simply halts.

To answer my own question, yes I am being unreasonable.  Shared memory
has not been set up at the time that process_preload_libraries is
called.  

Since lwlocks are allocated from postgres shared memory, I cannot assign
an lwlock from Veil's initialisation code.  Instead, I can make the
allocation of the lwlock the responsibility of the first session that
uses a Veil function but I need a lock to prevent a race.

My current thinking is to simply subvert one of the existing lwlocks
while I assign my own.  A better solution from my point of view would be
to simply move the call to process_preload_libraries to a point after
shared memory has been set up.  Is there some reason this could not be
done?

On a related note, I can see no way to release Veil's shared memory
segment when postgres is shut down.   Perhaps I should be thinking about
making the management of such shared memory segments something that
postgres does on behalf of its add-ins, though that seems presumptious.

I'd appreciate any suggestions, pointers, random thoughts, etc.
__
Marc


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] postgresql.conf basic analysis tool

2006-07-12 Thread Qingqing Zhou


Andrew Hammond [EMAIL PROTECTED] wrote
 Also, are there any other (simple for now) things I
 should look at in the process?


The shared memory estimiation logic is in
ipc/ipci.c/CreateSharedMemoryAndSemaphores(). If you want to get an accurate
number, you need to consider:
(1) different PostgreSQL versions;
(2) if EXEC_BACKEND is defined;
(3) other defines like BLCKSZ, NUM_SLRU_BUFFERS, etc.

So a better way IMHO is not to use perl script -- you have to reinvent the
shmem estimation logic. You can put the logic in a separate function in
backend and export it.

Regards,
Qingqing



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Updateable views for 8.2 or 8.3?

2006-07-12 Thread Jaime Casanova


On 7/12/06, Joe Conway [EMAIL PROTECTED] wrote:

Jaime Casanova wrote:

 is anybody working on the Bernd Helmle's updateable views patch? or
 know what the status of this is?

I was just wondering about this also. If no one else is working on it,
I'd like to try to push it through to completion for 8.2 myself. Can
anyone summarize what the open issues are?

Joe



if nobody step up i can do the list.

i think this is the last patch that he post:
http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php

i will try to rebuild a test script have made for this...

--
regards,
Jaime Casanova

Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning.
  Richard Cook

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

[HACKERS] speed checks ...

2006-07-12 Thread Marc G. Fournier



ignore ...


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED]  MSN . [EMAIL PROTECTED]
Yahoo . yscrappy   Skype: hub.orgICQ . 7615664

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] pgsql-patches considered harmful

2006-07-12 Thread Marc G. Fournier


On Wed, 12 Jul 2006, Magnus Hagander wrote:

There are list servers out there capable of simply ripping any 
attachments to a message (possibly over a certain size) and stick it on 
a website, replacing it with a link in the email. Is majordomo one of 
them?


Majordomo2 has a 'hook' for it, but, like most OSS software, nobody has 
had the requirement to actually code it ... any perl experts here 
interested in doing it?



Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED]  MSN . [EMAIL PROTECTED]
Yahoo . yscrappy   Skype: hub.orgICQ . 7615664

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] Implied Functional Index use

Simon Riggs [EMAIL PROTECTED] writes:
 Normally, I would not suggest that we do things only for certain data
 types only. In this case however, it seems that the reason it would work
 only for INTEGER and TEXT data types is that they are simple atomic
 datatypes that have the required properties. So doing this for those
 datatypes only seems permissable on a theoretical basis, rather than
 just because we can't be bothered to do it for more complex types.

There's nothing simple nor atomic about TEXT, and in fact until very
recently text_eq was NOT true equality by this definition.  See
discussions about hu_HU locale back in December.  A number of people
thought that fix was an ugly kluge, and so we may someday go back to
a behavior in which text_eq is again not true equality --- in particular
I'm dubious that such a restriction can survive once we support multiple
encodings/collations in the same database.

More generally, I don't believe in hacks that only work for a small
number of built-in types: to me, that's prima facie evidence that you
haven't thought the problem through.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Three weeks left until feature freeze

Jonah H. Harris [EMAIL PROTECTED] writes:
 On 7/12/06, David Fetter [EMAIL PROTECTED] wrote:
 Are they mutually exclusive?  I can imagine, at least for development
 purposes, that someone might want to install both.

 I believe both can be installed and running at the same time.  I don't
 really think anyone would want to run both, but that's just my
 opinion.

On what grounds do you not think that?  PL/J uses an external JVM,
PL/Java one that is running in the backend process.  (Or maybe it was
the other way 'round, I'm too tired to remember tonight.)  That's a
really fundamental difference that makes them suited for very different
applications; not to mention the resulting different licensing scenarios.

The points that have been made in this thread about PL/J not being
actively maintained are important, but other than that objection,
I can see no reason that PL/J wouldn't have an equal claim to inclusion
in core.  Perhaps more, because it gives us an extra layer of insulation
from JVM licensing questions.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Online index builds

Simon Riggs [EMAIL PROTECTED] writes:
 On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote:
 no regression tests yet.

 We'll need some performance tests that show that lock-hold time is
 *actually* reduced, given the shenanigans needed to get there.

Reducing lock hold time is not the point ... reducing the strength of
the lock at the cost of increased elapsed time is the point.

 We may need to have usage recommendations in the docs.

Agreed.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread Dave Cramer



On 12-Jul-06, at 10:44 PM, Tom Lane wrote:


Jonah H. Harris [EMAIL PROTECTED] writes:

On 7/12/06, David Fetter [EMAIL PROTECTED] wrote:
Are they mutually exclusive?  I can imagine, at least for  
development

purposes, that someone might want to install both.


I believe both can be installed and running at the same time.  I  
don't

really think anyone would want to run both, but that's just my
opinion.


On what grounds do you not think that?  PL/J uses an external JVM,
PL/Java one that is running in the backend process.  (Or maybe it was
the other way 'round, I'm too tired to remember tonight.)  That's a
really fundamental difference that makes them suited for very  
different
applications; not to mention the resulting different licensing  
scenarios.

No, this is correct.


The points that have been made in this thread about PL/J not being
actively maintained are important, but other than that objection,


I expect to see a new release shortly.
I can see no reason that PL/J wouldn't have an equal claim to  
inclusion
in core.  Perhaps more, because it gives us an extra layer of  
insulation

from JVM licensing questions.

regards, tom lane




---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] pre_load_libraries

Marc Munro [EMAIL PROTECTED] writes:
 ...  A better solution from my point of view would be
 to simply move the call to process_preload_libraries to a point after
 shared memory has been set up.  Is there some reason this could not be
 done?

That would make it impossible for a preloaded library to request any
shared memory of its own --- something that admittedly we don't have a
hook to support, but do we want to foreclose it permanently?

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Three weeks left until feature freeze


Dave Cramer wrote:


I expect to see a new release shortly.

Dave, I tried to obtain the source but whenever I try I get:

 [thhal]$ cvs -d 
:pserver:[EMAIL PROTECTED]:/home/projects/plj/scm login
 Logging in to 
:pserver:[EMAIL PROTECTED]:2401/home/projects/plj/scm

 CVS password:
 /home/projects/plj/scm: no such repository

I can browse the source using the web interface though. Judging from 
that, there's been no CVS activity since I last tried, i.e. august last 
year. Is the source being maintained somewhere else? How do I obtain the 
latest CVS? Judging from your statement a lot must have happened that 
would be interesting to look at.


Regards,
Thomas Hallgren


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] Three weeks left until feature freeze


Tom Lane wrote:

...  equal claim to inclusion
in core.  Perhaps more, because it gives us an extra layer of insulation
from JVM licensing questions.


Tom,
Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java 
builds and runs just fine with gcj and the above statement is completely false.


Dave,
What JVM requirements does PL/J currently have? What license implications are imposed by the 
components that it depends upon?


Regards,
Thomas Hallgren


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] Three weeks left until feature freeze


Thomas Hallgren wrote:

Tom Lane wrote:

...  equal claim to inclusion
in core.  Perhaps more, because it gives us an extra layer of insulation
from JVM licensing questions.


Tom,
Why to you persist talking about licensing issues with PL/Java? There 
are none. PL/Java builds and runs just fine with gcj and the above 
statement is completely false.


Just to further this with actual documentation :)


1.1 What license is used for libgcj?

libgcj is distributed under the GPL, with the 'libgcc exception'. 
This means that linking with libgcj does not by itself cause your 
program to fall under the GPL. See LIBGCJ_LICENSE in the source tree for 
more details.


Sincerely,

Joshua D. Drake




Dave,
What JVM requirements does PL/J currently have? What license 
implications are imposed by the components that it depends upon?


Regards,
Thomas Hallgren




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread Josh Berkus


Thomas,

I'm starting to have second thoughts about this suggestion.  I was 
enthusiastic about it at the summit, but I was unaware of the sheer size 
of PL/Java.  38,000 lines of code is 8% of the total size of Postgresql 
... for *one* PL.


Dave Cramer acquainted me with some of the difficulties of doing a Java 
PL today, and I understand why it needs to be that large.  However, 
38,000 lines of code -- much of it in a non-C language -- presents a 
possible debugging/maintenance major headache, especially if you someday 
left the project for some reason.


Maybe we do need to look at a plug-in build tool, instead.

Perhaps it's no surprise that I disagree when you say PL/J could be 
considered in the same light as PL/Java. Then again, I'm fairly biased ;-)


This attitude does you no credit, Thomas.

--Josh Berkus




---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Three weeks left until feature freeze

2006-07-12 Thread Josh Berkus


Tom,

 Perhaps more, because it gives us an extra layer of insulation

from JVM licensing questions.


I really don't see licensing issues as being relevant.   Your other 
concern certainly is, though.


--Josh


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Three weeks left until feature freeze


Josh Berkus wrote:


Perhaps it's no surprise that I disagree when you say PL/J could be 
considered in the same light as PL/Java. Then again, I'm fairly 
biased ;-)


This attitude does you no credit, Thomas.

My diplomatic skills are somewhat limited :-) I might be blunt at times. 
I'm sure there are other more subtle ways to get the message through. 
I'm trying to be honest and up-front. IMO, that should count for something.


Regards,
Thomas Hallgren


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] Three weeks left until feature freeze


Thomas Hallgren wrote:

Tom Lane wrote:

Thomas Hallgren [EMAIL PROTECTED] writes:
 
Why to you persist talking about licensing issues with PL/Java? There 
are none. PL/Java builds and runs just fine with gcj and the above 
statement is completely false.



Um ... if you use it with gcj, there may or may not be any licensing
problems (please recall we are trying to be a BSD-only project, not a
BSD-and-LGPL project),

You have no problems using gcc, gnu-make, etc. What's the difference?


Well there is a couple of literal differences.

gcc, gnu-make are irrelevant. What is relevant is libc which is LGPL.

Gcj IS GPL, not LGPL :( it just has an exception clause

Keep in mind that that there are all kinds of oddities when mixing 
licenses. Is Sun's JVM GPL compatible? If not, the plJava can't use it.


What happens when the FSF inevitably removes the license clause and 
makes it pure GPL?


Now all of this being said, I doubt there is actually an issue here because:

It doesn't HAVE TO BE BUILT, it is not a derivative product.

It doesn't ship with the JVM which means it is up to the user to break 
the license not the PostgreSQL project...


However that last one is bad mojo :(

Sincerely,

Joshua D. Drake






 but what of people who use some other JVM?
It's not like gcj works for everyone yet.

  
What of them? If they decide to use another JVM, well, then let them. I 
don't see where that becomes a licensing problem from PostgreSQL.


Regards,
Thomas Hallgren




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Three weeks left until feature freeze

Thomas Hallgren [EMAIL PROTECTED] writes:
 Why to you persist talking about licensing issues with PL/Java? There are 
 none. PL/Java 
 builds and runs just fine with gcj and the above statement is completely 
 false.

Um ... if you use it with gcj, there may or may not be any licensing
problems (please recall we are trying to be a BSD-only project, not a
BSD-and-LGPL project), but what of people who use some other JVM?
It's not like gcj works for everyone yet.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Three weeks left until feature freeze


Tom Lane wrote:

Thomas Hallgren [EMAIL PROTECTED] writes:
  
Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java 
builds and runs just fine with gcj and the above statement is completely false.



Um ... if you use it with gcj, there may or may not be any licensing
problems (please recall we are trying to be a BSD-only project, not a
BSD-and-LGPL project),

You have no problems using gcc, gnu-make, etc. What's the difference?


 but what of people who use some other JVM?
It's not like gcj works for everyone yet.

  
What of them? If they decide to use another JVM, well, then let them. I 
don't see where that becomes a licensing problem from PostgreSQL.


Regards,
Thomas Hallgren


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Three weeks left until feature freeze


Joshua D. Drake wrote:
What happens when the FSF inevitably removes the license clause and 
makes it pure GPL?


I'm sorry but I don't follow. You're saying that it's inevitable that 
FSF will remove the 'libgcc' exception from libgcj? Why on earth would 
they do that? My guess is that it will go the other way (i.e. LGPL). 
What's the logic in having different licenses on libg++ and libgcj?


Now all of this being said, I doubt there is actually an issue here 
because:


It doesn't HAVE TO BE BUILT, it is not a derivative product.

Well, assume that FSF indeed did remove the exception. It would take me 
30 minutes or so to create a substitute BSD licensed dummy JNI library 
with associated headers that would allow PL/Java to be built without any 
external modules at all. It's then completely up to the user what he/she 
wants to slot in as a replacement.


Regards,
Thomas Hallgren


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Three weeks left until feature freeze


Josh Berkus wrote:

Thomas,

I'm starting to have second thoughts about this suggestion.  I was 
enthusiastic about it at the summit, but I was unaware of the sheer size 
of PL/Java.  38,000 lines of code is 8% of the total size of Postgresql 
... for *one* PL.


Dave Cramer acquainted me with some of the difficulties of doing a Java 
PL today, and I understand why it needs to be that large.  However, 
38,000 lines of code -- much of it in a non-C language -- presents a 
possible debugging/maintenance major headache, especially if you someday 
left the project for some reason.


OK. You're the one that suggested this submission attempt. There's not much point in 
pursuing it if you have second thoughts.


 Maybe we do need to look at a plug-in build tool, instead.

Right, something that would allow PL/Java to participate in a build farm. That would be cool 
and also resolve a some of the issues.


Regards,
Thomas Hallgren

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Online index builds

2006-07-12 Thread Greg Stark

Simon Riggs [EMAIL PROTECTED] writes:

 On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote:
  no regression tests yet.
 
 We'll need some performance tests that show that lock-hold time is
 *actually* reduced, given the shenanigans needed to get there.

I'm not sure what you mean by lock-hold time. Online index builds
effectively take *no* locks in the user-visible sense that regular index
builds do. Other transactions can insert, update, delete continuously
throughout the entire process.

The only locks that are taken are

1) a ShareUpdateExclusiveLock which blocks vacuum from running on the table
   being indexed. This is taken by both phase 1 and phase 2. (Actually I had
   the wrong lock in the patch I emailed in one place. Fixed in my source tree
   here)

2) An ExclusiveLock that is taken momentarily and immediately released. Even
   if that can never be acquired due to a busy system it can eventually
   proceed anyways as long as there are no long-running transactions that are
   refusing to commit.

That said we do need some performance tests to get an idea how long phase 2
takes for large tables. The additional index and heap scan and tid sort could
take a substantial amount of time though never as long as the original index
build done in phase 1.

What's worse is that in some cases the merge could potentially be doing a lot
of retail index inserts. I have no good intuition for how long those will take
relative to the wholesale index build method, especially since for some index
methods like GIN retail inserts are extremely expensive.

So for indexes that don't have a lot of records that need to be inserted
individually what I expect -- and what I put in the docs -- is something under
100% time penalty for an online index build. In fact I expect it to be more
like 50% though it depends on how wide the original index. For ones that do
have lots of records mutated for phase 2 all bets are off.

 We may need to have usage recommendations in the docs.

I'm writing docs now. I'm trying to find a happy medium between explaining all
the issues and spamming the docs with lots of discussion. Right now what I
have is a single paragraph in the create_index man page that refers to the
Postgres manual where I list the issues in more depth.

I also still have to get some kind of regression tests. I don't think we have
any concurrent regression tests currently, do we? To thoroughly test it will
be quite hard. Some of the corner cases are extremely narrow or require very
particular types of transactions running with very specific timing.

-- 
greg


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] [PATCHES] [patch 0/9] annual pgcrypto update

2006-07-12 Thread Neil Conway

On Thu, 2006-07-13 at 00:50 -0400, Tom Lane wrote:
 This has broken two out of the four buildfarm members that reported
 in the last half hour :-(  I think kudu does not like // comments,
 not sure what kookaburra is on about.

BTW, you've switched your animal names :) I fixed the C++-style comment.

Marko, can you take a look at what is causing this regression test
failure? The failing machine is kudu:

http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=kudubr=HEAD

The regression.diffs are:

*** ./expected/pgp-pubkey-decrypt.out   Wed Jul 12 21:30:59 2006
--- ./results/pgp-pubkey-decrypt.outWed Jul 12 21:39:15 2006
***
*** 544,555 
  -- password-protected secret key, wrong password
  select pgp_pub_decrypt(dearmor(data), dearmor(seckey), 'foo')
  from keytbl, encdata where keytbl.id=5 and encdata.id=1;
! ERROR:  Corrupt data
  -- password-protected secret key, right password
  select pgp_pub_decrypt(dearmor(data), dearmor(seckey), 'parool')
  from keytbl, encdata where keytbl.id=5 and encdata.id=1;
!  pgp_pub_decrypt 
! -
!  Secret msg
! (1 row)
! 
--- 544,551 
  -- password-protected secret key, wrong password
  select pgp_pub_decrypt(dearmor(data), dearmor(seckey), 'foo')
  from keytbl, encdata where keytbl.id=5 and encdata.id=1;
! ERROR:  Unsupported cipher algorithm
  -- password-protected secret key, right password
  select pgp_pub_decrypt(dearmor(data), dearmor(seckey), 'parool')
  from keytbl, encdata where keytbl.id=5 and encdata.id=1;
! ERROR:  Unsupported cipher algorithm

-Neil



---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Three weeks left until feature freeze



Well, assume that FSF indeed did remove the exception. It would take me 
30 minutes or so to create a substitute BSD licensed dummy JNI library 
with associated headers that would allow PL/Java to be built without any 
external modules at all. It's then completely up to the user what he/she 
wants to slot in as a replacement.


Do we want to do that? I mean (and I am not saying it is, I am asking) 
is that a bit grey? I would prefer it be black and white.


Are their JVMs that are BSD compatible? It is my understanding that you 
can ship Java (I could be completely on crack here) in a closed source 
product without issue right?


If so... then wouldn't our argument be to strongly suggest that they use 
the Sun JVM (or IBM if that is relevant?).


Sincerely,

Joshua D. Drake




Regards,
Thomas Hallgren




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Three weeks left until feature freeze


Joshua D. Drake wrote:


Well, assume that FSF indeed did remove the exception. It would take 
me 30 minutes or so to create a substitute BSD licensed dummy JNI 
library with associated headers that would allow PL/Java to be built 
without any external modules at all. It's then completely up to the 
user what he/she wants to slot in as a replacement.


Do we want to do that? I mean (and I am not saying it is, I am asking) 
is that a bit grey? I would prefer it be black and white.


The JNI API is an open standard so I have every right to create a BSD 
licensed dummy for it. The user may choose a JVM from IBM, Sun, BEA, or 
other (like GCJ) to run. That's the essence of having a standardized 
API. What can possibly be 'grey' about that?


Regards,
Thomas Hallgren


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] [PATCHES] [patch 0/9] annual pgcrypto update