Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Tommi Maekitalo]

Am Donnerstag, 5. Dezember 2002 05:22 schrieb Lamar Owen:
 [cc: list trimmed]

 On Wednesday 04 December 2002 22:52, Philip Warner wrote:
  At 05:48 PM 4/12/2002 -0800, Christopher Kings-Lynne wrote:
  Lack of marketing is one of Postgres's major problems.
 
  What are the consequences of the problem?

 Actually, lack of easy upgrading is one of PostgreSQL's major problems

 But lack of focused marketing -- truthful, not, as has been said, like the
 'Database HOWTO' -- is a real problem.  It would be nice to increase our
 usage.

  If that is what we want, then fine. But I don't want to see any part of
  the development effort distorted or the existing user base inconvenienced
  in an effort to purely gain that market share. I usually associate
  increased marketing with decreased quality, and I think the causality
  works *both* ways.

 ISTM there's a separate, non-code-developer group doing this.  It doesn't
 seem to take away _any_ developer resources to do an advocacy site.

 However, I seriously question the need in the long term for our sites to be
 as fractured as they are.  Good grief!  We've got advocacy.postgresql.org,
 techdocs.postgresql.org, odbc.postgresql.org, gborg.postgresql.org,
 developer.postgresql.org, jdbc.postgresql.org, etc.  Oh, and we also have
 www.postgresql.org on the side?  I think not.  Oh, and they are fractured
 in their styles -- really, guys, we need a unified style here.

Hi,

there are lots of sites talking about postgresql. But if someone hear about 
postgresql he sure tries www.postgresql.org. There he just get a list of 
mirrors. Not really a good start. But worse: there is no links to gborg, 
advocacy, techdocs, ... Advocacy should be found at www.postgresql.org and 
have links to the other pages. I found gborg when reading the mailinglistst. 
It is something like a insidertip.

www.apache.org has a much better structure. You go to www.apache.org and get a 
welcome-message and links to subprojects as the webserver.

Another point that comes to my mind is design. I'm not a designer, but I like 
the design of www.postgresql.org but not advocacy.postrgresql.org.


Tommi

-- 
Dr. Eckhardt + Partner GmbH
http://www.epgmbh.de

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Justin Clift]

Hi Tommi,

Tommi Maekitalo wrote:
snip

Hi,

there are lots of sites talking about postgresql. But if someone hear about 
postgresql he sure tries www.postgresql.org. There he just get a list of 
mirrors. Not really a good start. But worse: there is no links to gborg, 
advocacy, techdocs, ... Advocacy should be found at www.postgresql.org and 
have links to the other pages. I found gborg when reading the mailinglistst. 
It is something like a insidertip.

There is a new front page for the www.postgresql.org site that was 
recently finished, and will be moved into the correct place soon.  You 
can view it for now at wwwdevel.postgresql.org.

The new front page has links to the other main websites, so it should 
help people find the information they need in a much easier way.  :-)

Hope that's helpful to know.

:-)

Regards and best wishes,

Justin Clift


snip
Tommi




--
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
- Indira Gandhi


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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: Porting from MySQL to PostgreSQL (was: [HACKERS] pgsql 7.2.3

[Devrim GUNDUZ]

Hi,

On Mon, 2002-12-09 at 10:24, SEGUERRA FRANCIS TED ARANAS wrote:

 how do i port from mysql to postgresql?..

http://techdocs.postgresql.org/#convertfrom

Best regards,
.

-- 
Devrim GUNDUZ 
TR.NET Sistem Destek Uzmani

Tel : (312) 295 93 18  Fax : (312) 295 94 94 Tel : (216) 542 90 00


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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] pgsql 7.2.3 crash

[SEGUERRA FRANCIS TED ARANAS]

how do i port from mysql to postgresql?...

thanks bruce,
francis

-- 
ov3rr|d3r


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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Kevin Brown]

Vince Vielhaber wrote:
 On Sun, 8 Dec 2002, Justin Clift wrote:
 
  Vince Vielhaber wrote:
   On Thu, 5 Dec 2002, Robert Treat wrote:
  
  
  Well, my previous employer uses postgresql, but they were under constant
  assault from their clients to use oracle or db2.  Technically there was no
  reason to switch, but if your choice is switch databases or go out of
  business, there really isn't much choice.
  
  
   That tells me their clients wanted a commercial database, not one that's
   open source.  All the marketing in the world won't change that.
 
  Really?
 
  Why do you say that?
 
 Because of this taken from the above quoted text:
 
 they were under constant assault from their clients to use oracle or db2
 
 Last I looked neither Oracle or DB2 were open source, but they both just
 happen to be commercial and I don't see mysql mentioned.
 
 Anything else you don't understand about that?

There are a number of reasons their clients could have been clamoring
for DB2 or Oracle, only some of which are related to the fact that
they're commercial, closed-source databases:

1.  They already have significant in-house expertise with one or the
other product.

2.  They need 24x7 support, and are convinced that they'll get better
support for Oracle or DB2 than anything else.

3.  They want a company to blame in case things go wrong.

4.  They require certain capabilities that they believe only DB2 or
Oracle can provide.

5.  They have an established partnership with IBM or Oracle.

6.  Some combination of the above.


Some of those reasons are such that it might be possible (depending on
the specifics of the situation) to successfully market PostgreSQL (or
even MySQL) to them, and some of them aren't.  It just depends.

And that's why it's a bad idea to simply discard that situation as one
in which it would be impossible to market PostgreSQL.


Marketing is the art of convincing someone that they want your
product.  Since the keyword here is want, it's an art that combines
reason and emotion.  Even if the situation seems logically hopeless
(that is, there's no logical reason for the customer to prefer your
product over another), you may still manage to successfully market
your product to them by appealing to their emotions.  Happens all the
time.

My personal feeling is that in the case of PostgreSQL, it should be
marketed primarily using reason.  More precisely, it should *not* be
marketed to someone for whom a different product would better suit
them.  That, to me, would be shady at best and would eventually become
a blemish on the reputation of the PostgreSQL community.  But it
doesn't mean giving up just because the client thinks he wants a
commercial database: he may well want something else that a commercial
database just happens to provide.

If you're trying to sell someone on PostgreSQL, it behooves you to
figure out what their real needs are first.  Their actual needs may be
significantly different from what they tell you they want.



-- 
Kevin Brown   [EMAIL PROTECTED]

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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Shridhar Daithankar]

On 9 Dec 2002 at 1:20, Kevin Brown wrote:

 2.  They need 24x7 support, and are convinced that they'll get better
 support for Oracle or DB2 than anything else.

I have experienced what oracle support means for 24x7. I wouldn't even wish 
that penalty for my worst enemy.

I can tell a story about it but I digress. Details aren't important though 
true. 

What really matters is how kindly and dearly you stand by your product. That is 
where all support originates.. Rest is marketing..

Bye
 Shridhar

--
I have never understood the female capacity to avoid a direct answer toany 
question.   -- Spock, This Side of Paradise, stardate 3417.3


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

[Kevin Brown]

Joe Conway wrote:
 The second case is usually something like an insert into the employee table 
 fires off an email to IT to create a login and security to make a badge. 
 Commonly we turn off workflows (by disabling their related triggers) in our 
 development and test databases so someone doesn't disable the CEO's login 
 when we fire him as part of our testing! I think in this scenario it is 
 better to be able to disable the trigger globally ;-)

I think in this scenario it's probably better to not fire the CEO,
gratifying as it may be!  :-)



-- 
Kevin Brown   [EMAIL PROTECTED]

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

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Vince Vielhaber]

On Sun, 8 Dec 2002, Josh Berkus wrote:

 But once Postgres has been packaged, we need to have a group making a
 loud enough noise to get the world to pay attention.   I'm not asking
 everyone on this list to participate, but I am asking everyone on this
 list to recognize the utility of the effort.

Here are my main problems with it.

1) They're marketing to those that are already sold on it.
2) They are, or at least were, insisting that I join their list to
   stay informed on what they're doing.
3) They need to learn HOW to market from someone who knows (not me)
   how or they'll never be taken seriously.

That's all I'm going to say on this subject.

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Robert Treat]

On Mon, 09 Dec 2002 07:29:55 -0500, Vince Vielhaber wrote:
 On Sun, 8 Dec 2002, Josh Berkus wrote:
 
 But once Postgres has been packaged, we need to have a group making a
 loud enough noise to get the world to pay attention.   I'm not asking
 everyone on this list to participate, but I am asking everyone on this
 list to recognize the utility of the effort.
 
 Here are my main problems with it.
 
 1) They're marketing to those that are already sold on it. 

I think we've already shown why it doesn't hurt to market to the
converted. I'll add that if you compare the 7.2 press release with the
7.3 press release, you'll see none of the technical content was removed. 

 2) They are,
 or at least were, insisting that I join their list to
stay informed on what they're doing.

I think it was only suggested that you join since you obviously have a
lot of feedback you'd like to give to the group. Since a lot of people on
-hackers don't want to be involved in the process, it seemed a bad idea
to post all of the detail work to this list.

 3) They need to learn HOW to market from someone who knows (not me)
how or they'll never be taken seriously.
 

I've seen more posts saying that until you get a decent website your
not going to be taken seriously than anything else, by far. While I'm
hoping that's not entirely true, I do agree that until we get a coordinated and
open web development process the advocacy group is going to have a much
harder go of it.

Robert Treat

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

http://archives.postgresql.org

[HACKERS] DBD::Pg module on Windows

[Rod Taylor]

Does anybody know where I can find a newer DBD::Pg module for Windows
NT?   The only pre-compiled one I can find is 0.98, which is based on a
PostgreSQL 7.0 library set.
-- 
Rod Taylor [EMAIL PROTECTED]

PGP Key: http://www.rbt.ca/rbtpub.asc



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

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Tom Lane]

Vince Vielhaber [EMAIL PROTECTED] writes:
 1) They're marketing to those that are already sold on it.

I think the upshot of the prior discussion was that the outside press
release shouldn't have been used as the release announcement for the
existing mailing lists.  Fine, they made a one-time mistake.

 2) They are, or at least were, insisting that I join their list to
stay informed on what they're doing.

It seems to me that people have made it perfectly clear that they don't
want to hear about marketing on the -hackers or -general lists.  Taking
it to a marketing-specific list seems like exactly the right response.
Where do you think it should be discussed?

regards, tom lane

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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Let's create a release team

[Tom Lane]

Dan Langille [EMAIL PROTECTED] writes:
 Let's create a release team.  This strategy is one well established 
 in other projects and in industry.  For lack of a better starting 
 reference, let me suggest http://www.freebsd.org/releng/charter.html 
 as a starting point for consideration.  See also 
 http://www.freebsd.org/releng/index.html.  

 This will also lighten the load on the core team allowing them to 
 focus on development and such.  

I don't really see any value-added here.  The core committee's only
routinely-exercised function is to organize releases; separating that
out would leave core with nothing to do.  Also, to the extent that
core has any real or perceived authority in the project, I think it
comes from having control of the release process --- there's surely
no other reason for people to defer to the core team as a group (as
opposed to whatever respect might be accorded to individual people
as a result of their individual contributions).  So ISTM such a
reorganization would leave the core committee as a figurehead and make
the release team into the effective new core.

regards, tom lane

---(end of broadcast)---
TIP 3: 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: Porting from MySQL to PostgreSQL (was: [HACKERS] pgsql 7.2.3

[SEGUERRA FRANCIS TED ARANAS]

thanks






On 9 Dec 2002, Devrim GUNDUZ wrote:

 Hi,
 
 On Mon, 2002-12-09 at 10:24, SEGUERRA FRANCIS TED ARANAS wrote:
 
  how do i port from mysql to postgresql?..
 
 http://techdocs.postgresql.org/#convertfrom
 
 Best regards,
 .
 
 

-- 
ov3rr|d3r


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] proposal: array utility functions phase 1

[Tom Lane]

Joe Conway [EMAIL PROTECTED] writes:
 Yes, this is exactly what I was yearning to do. Was there a spec or technical
 reason (or both) for not allowing the following?

select * from array_values(g.grolist), pg_group g where g.groname = 'g2';

This seems fairly unworkable to me as-is.  By definition, WHERE selects
from a cross-product of the FROM tables; to make the above do what you
want, you'd have to break that fundamental semantics.  The semantics of
explicit JOIN cases would be broken too.

What we need is some kind of explicit multi-level SELECT operation.
Perhaps it would help to think about the analogy of aggregates of
aggregate functions, which are impossible to express properly in a
single SELECT but work nicely given subselect-in-FROM.
Subselect-in-FROM doesn't seem to get this job done though.

Right offhand I don't see any reasonable syntax other than
function-in-the-SELECT-list, which shoots us right back into the
messinesses of the Berkeley implementation.  However, we do now have the
precedent of the table-function AS clause.  Does it help any to do
something like

SELECT grosysid, array_values(grolist) AS (array_index,member_id)
FROM pg_group where groname = 'g2';

(Again you could wrap this in an outer SELECT to transform the
member_ids to member_names.)

The real problem with the Berkeley approach shows up when you consider
what happens with multiple table functions called in a single SELECT.
The code we currently have produces the cross-product of the implied
rows (or at least it tries to, I seem to recall that it doesn't
necessarily get it right).  That's pretty unpleasant, and though you can
filter the rows in an outer SELECT, there's no way to optimize the
implementation into a smarter-than-nested-loop join.

It seems like somehow we need a level of FROM/WHERE producing some base
rows, and then a set of table function calls to apply to each of the
base rows, and then another level of WHERE to filter the results of the
function calls (in particular to provide join conditions to identify
which rows to match up in the function outputs).  I don't see any way to
do this without inventing new SELECT clauses out of whole cloth
... unless SQL99's WITH clause helps, but I don't think it does ...

 How ugly/difficult would it be to allow the planner to interrogate the 
 function and let the function report back a tupledesc based on the actual 
 runtime input parameters?

Parse-time, not run-time.  It could be done --- IIRC, the auxiliary
function info call we introduced in the V1 fmgr protocol was
deliberately designed to allow expansion in this sort of direction.
But it would have to take a tupledesc (or some similar static
description) and return another one.

regards, tom lane

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

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Josh Berkus]

Vince,

 Here are my main problems with it.
 
 1) They're marketing to those that are already sold on it.

First off ... not they, you.  I'm a member of Advocacy; so are
Robert, Justin, Neil, Marc, Bruce and several other members of this
list.   The advocacy group is not some privately sponsored bunch of
marketeers; *we* are your fellow contributors.

Yes, we should have released a different version of the announcement to
the internal lists.   I believe that I have already explained how that
happened.

 2) They are, or at least were, insisting that I join their list to
stay informed on what they're doing.

Unless you don't want to stay informed.   In which case, you're welcome
not to, and one or more Advocacy people will join wwwdevel to keep
links synchronized.  Nobody's going to make you do anything.  This is
Open Source.

 3) They need to learn HOW to market from someone who knows (not me)
how or they'll never be taken seriously.

One of our volunteers is a professional PR person.   Two are periodical
writers.  I started (with 2 partners) the OpenOffice.org Marketing
Project, which was cited by one columnist (Amy Wohl) as a better
volunteer marketing team than Sun could put together for a
million-dollar budget (paraphrased).  3 of us are small business
owners.  I think we have as much or more combined experience as the
marketing department of any start-up, without the baggage.

Also, half a marketing effort is better than none.   At the very least,
we need to keep Postgres in the press, else we are likely to see
PostgreSQL fade into permanent obscurity.  The technology world is full
of technically good but poorly marketed products -- FoxPro anyone?
Paradox?  Beta video?  Amiga?

Last week I got a 5-page long database developer survey from EvansData.
 It mentioned 10 other database platforms -- including Ingres! -- but
not PostgreSQL.  I personally don't want to see that again.

Sure, we got off to a rocky start.   However, I will point out that our
first release happened to fall on a major American holiday; this made
it extra hard to organize the effort, and things didn't work out well.
  But the answer to that is not to abandon the effort, but to plan and
prepare better in the future.

I would also be grateful if us folks on the Advocacy team could look to
Hackers to make sure that we *aren't* going off on a tangent, or
pushing Postgres in a way that's inconsistent with the development
goals for the database.   We *want* Advocacy to be an integral part of
the Postgres community, serving the general goal of making Postgres the
best possible ORDBMS in existence.  

-Josh Berkus


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

Re: [PATCHES] [HACKERS] Patch to make Turks happy.

[Bruce Momjian]

Peter, is that patch OK for 7.3.1?  I am not sure.

---

Peter Eisentraut wrote:
 Bruce Momjian writes:
 
  I am not going to apply this patch because I think it will mess up the
  handling of other locales.
 
 This patch looks OK to me.  Normally, character set names should use
 identifier case-folding rules anyway, so seems to be a step in the right
 direction.  Much better than saying that users of certain locales can't
 properly use PostgreSQL.
 
 
 
  ---
 
  Nicolai Tufar wrote:
   Hi,
  
   Yet another problem with Turkish encoding. clean_encoding_name()
   in src/backend/utils/mb/encnames.c uses tolower() to convert locale
   names to lower-case. This causes errors if locale name contains
   capital I and current olcale is Turkish. Some examples:
  
   aaa=# \l
 List of databases
  Name| Owner | Encoding
   ---+---+--
aaa   | pgsql | LATIN5
bbb   | pgsql | LATIN5
template0 | pgsql | LATIN5
template1 | pgsql | LATIN5
   (4 rows)
   aaa=# CREATE DATABASE ccc ENCODING='LATIN5';
   ERROR:  LATIN5 is not a valid encoding name
   aaa=# \encoding
   SQL_ASCII
   aaa=# \encoding SQL_ASCII
   SQL_ASCII: invalid encoding name or conversion procedure not found
   aaa=# \encoding LATIN5
   LATIN5: invalid encoding name or conversion procedure not found
  
  
   Patch, is a simple change to use ASCII-only lower-case conversion
   instead of locale-dependent tolower()
  
   Best regards,
   Nic.
  
  
  
  
  
  
   *** ./src/backend/utils/mb/encnames.c.origMon Dec  2 15:58:49 2002
   --- ./src/backend/utils/mb/encnames.c Mon Dec  2 18:13:23 2002
   ***
   *** 407,413 
 for (p = key, np = newkey; *p != '\0'; p++)
 {
 if (isalnum((unsigned char) *p))
   ! *np++ = tolower((unsigned char) *p);
 }
 *np = '\0';
 return newkey;
   --- 407,416 
 for (p = key, np = newkey; *p != '\0'; p++)
 {
 if (isalnum((unsigned char) *p))
   ! if (*p = 'A'  *p = 'Z')
   ! *np++ = *p + 'a' - 'A';
   ! else
   ! *np++ = *p;
 }
 *np = '\0';
 return newkey;
  
  
   ---(end of broadcast)---
   TIP 4: Don't 'kill -9' the postmaster
  
 
 
 
 -- 
 Peter Eisentraut   [EMAIL PROTECTED]
 
 
 
 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [PATCHES] [HACKERS] Patch to make Turks happy.

[Peter Eisentraut]

Bruce Momjian writes:

 Peter, is that patch OK for 7.3.1?  I am not sure.

Definitely.  It's a bug fix.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Peter Eisentraut]

Robert Treat writes:

 I think we've already shown why it doesn't hurt to market to the
 converted. I'll add that if you compare the 7.2 press release with the
 7.3 press release, you'll see none of the technical content was removed.

Compare the 7.3 release notes, written for the most part by Bruce
Momjian and revised by a couple of other developers, to the press
release, written by people who were obviously ill-informed.

Release notes:

   Schemas
  Schemas allow users to create objects in their own namespace so
  two people or applications can have tables with the same name.
  There is also a public schema for shared tables. Table/index
  creation can be restricted by removing permissions on the
  public schema.

Press release:

   Schemas
PostgreSQL now joins the handful of ORDBMS's to support
the SQL 92 Schema specification, improving both enterprise
database management and security through the use of namespaces.

This not only removes all information about the actual use of schemas,
it contains completely bogus information, because SQL 92 is obsolete,
there is no SQL Schema specification, and none of this has to do
with being an ORDBMS.  And besides, whose hands were used to do the
counting?


Release notes:

   Drop Column
  PostgreSQL now supports the ALTER TABLE ... DROP COLUMN
  functionality.

Press release:

   void


Release notes:

   Table Functions
  Functions returning multiple rows and/or multiple columns are
  now much easier to use than before. You can call such a table
  function in the SELECT FROM clause, treating its output like a
  table. Also, PL/pgSQL functions can now return sets.

Press release:

  Table Functions
PostgreSQL version 7.3 has greatly simplified returning result sets
of rows and columns in database functions.  This significantly
enhances the useability of stored procedures in PostgreSQL, and will
make it even easier to port Oracle applications to PostgreSQL.

Again, this removes all details about how the feature can be used, and
again it inserts completely bogus information.  There are no sets of
columns, and PostgreSQL does not have stored procedures.  Also, it
makes it look as though PostgreSQL exists merely to reimplement
Oracle.


Release notes:

   Prepared Queries
  PostgreSQL now supports prepared queries, for improved
  performance.

Press release:

   - Prepared queries for maximized performance on common requests.

I'm curious to know how the marketing department determined that this
is, in fact, the maximal performance.


Release notes:

   Dependency Tracking
  PostgreSQL now records object dependencies, which allows
  improvements in many areas. DROP statements now take either
  CASCADE or RESTRICT to control whether dependent objects are
  also dropped.

Press release:

   - Enhanced dependency tracking for complex databases.

Again, all relevant information dropped, replaced by marketing fluff.


Release notes:

   Privileges
  Functions and procedural languages now have privileges, and
  functions can be defined to run with the privileges of their
  creator.

Press release:

Security Advances
In response to community demands, PostgreSQL has added schema,
function, and other permissions and settings to increase the database
administrator's granular control over security.

Information dropped, replaced by broad and repetitive verbiage.  But
at least they didn't write, in response to market pressures.


And my personal favorite is this:

Release notes:

   Internationalization
  Both multibyte and locale support are now always enabled.

Press release:

- Supports data in many international characters sets (UNICODE, EUC_JP,
  EUC_CN, EUC_KR, JOHAB, EUC_TW, ISO 8859-1 ECMA-94, KOI8, WIN1256, etc...)

That is just plain wrong.  Support for various character sets is years
old.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] DB Tuning Notes for comment...

[Robert Treat]

On Sun, 2002-12-08 at 09:41, Philip Warner wrote:
 Any comments or suggestions would be welcome.
 

first and foremost, this is really excellent work! We need to look into
getting this info into the standard documentation and/or Bruce's tuning
guide.

 
 Tuning
 ==
 
 1. max_fsm_relations
 
 
 First of all, the free space manager is useless at managing free space if 
 it can not map all relations (including system relations and toast 
 relations). The following query should give the correct ballpark:
 
  select count(*) from pg_class where not relkind in ('i','v');
 

It should be noted that if you have multiple databases, you'll need to
get the number of relations minus the system tables for each database,
then add in the number of system tables.

 Set max_fsm_relations to a number greater than this. Add extra to deal with 
 any tables you will create etc.  It costs 40 bytes per table, so be 
 generous - if it is set too low, you will get bizarre space usage.
 
 
 2. VACUUM Frequency
 ---
 
 Ideally VACUUM should run constantly; a future version will support 
 something like it. But for now, vacuum should be run when a significant 
 amount of data has been inserted, updated or deleted. The definition of 
 'significant' is not immediately obvious.


I don't think this is entirely true. On tables that have large numbers
of inserts, but no updates or deletes, you do not need to run vacuum. It
might be helpful to run analyze on these tables if your inserting enough
data to change the statistical relationships, but vacuum itself is not
needed. 
 
 Most tables will *not* be updated frequently in most databases; such tables 
 can be vacuumed irregularly, or vacuumed when the more frequently updated 
 tables are vacuumed.
 
 In our specific case we have one table that has a few rows ( 1000), but it 
 is updated as many as 3 times per second. In this case, we chose a 5 minute 
 interval, which results in at worst 1000 'dead' rows in the table as a 
 result of the updates. Since it was such a small table, we saw no reason to 
 vacuum every minute, or even constantly.

I have some similar tables in my system, with between 250 and 3500 rows.
These tables turn over at least every 15 minutes, so I have decided on a
10 minute vacuum interval. As with Phillip's, since they are small
tables, more frequent vacuuming seemed excessive. 

 
 For larger or more complex tables, the output of VACUUM ANALYZE must be used.
 
snip

again, great work Philip.

Robert Treat


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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] DB Tuning Notes for comment...

[Scott Shattuck]

Robert Treat wrote:

On Sun, 2002-12-08 at 09:41, Philip Warner wrote:


Any comments or suggestions would be welcome.




first and foremost, this is really excellent work! We need to look into
getting this info into the standard documentation and/or Bruce's tuning
guide.



Seconded!




Tuning
==

1. max_fsm_relations


First of all, the free space manager is useless at managing free space if 
it can not map all relations (including system relations and toast 
relations). The following query should give the correct ballpark:

select count(*) from pg_class where not relkind in ('i','v');



It should be noted that if you have multiple databases, you'll need to
get the number of relations minus the system tables for each database,
then add in the number of system tables.



Set max_fsm_relations to a number greater than this. Add extra to deal with 
any tables you will create etc.  It costs 40 bytes per table, so be 
generous - if it is set too low, you will get bizarre space usage.


2. VACUUM Frequency
---

Ideally VACUUM should run constantly; a future version will support 
something like it. But for now, vacuum should be run when a significant 
amount of data has been inserted, updated or deleted. The definition of 
'significant' is not immediately obvious.



I don't think this is entirely true. On tables that have large numbers
of inserts, but no updates or deletes, you do not need to run vacuum. It
might be helpful to run analyze on these tables if your inserting enough
data to change the statistical relationships, but vacuum itself is not
needed. 
 

In my experience I've seen tables with numerous indexes continue to 
benefit greatly from vacuum/vacuum full operations when large volumes of 
inserts are performed. This is true even when the update/delete activity 
on the base table itself is manageable. While dropping and recreating 
the index after loading is possible in some cases, my general comment is 
that index maintenance is an issue you should keep in mind when 
designing your vacuum strategy.



Most tables will *not* be updated frequently in most databases; such tables 
can be vacuumed irregularly, or vacuumed when the more frequently updated 
tables are vacuumed.

In our specific case we have one table that has a few rows ( 1000), but it 
is updated as many as 3 times per second. In this case, we chose a 5 minute 
interval, which results in at worst 1000 'dead' rows in the table as a 
result of the updates. Since it was such a small table, we saw no reason to 
vacuum every minute, or even constantly.


I have some similar tables in my system, with between 250 and 3500 rows.
These tables turn over at least every 15 minutes, so I have decided on a
10 minute vacuum interval. As with Phillip's, since they are small
tables, more frequent vacuuming seemed excessive. 


For larger or more complex tables, the output of VACUUM ANALYZE must be used.



snip

again, great work Philip.

Robert Treat


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

http://www.postgresql.org/users-lounge/docs/faq.html




ss


Scott Shattuck
Technical Pursuit Inc.




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

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] Sequence Cleanup

[Rod Taylor]

Below is a short list of TODOs on sequences I wish to tackle over the
next week.


CREATE SEQUENCE:
- Addition of NO MAXVALUE and NO MINVALUE options, which use the system
implementation settings -- for SQL2002 compliance, and makes ALTER
SEQUENCE slightly easier.

ALTER SEQUENCE:
- Supports RESTART WITH, + options from Create Statement (including NO
MAXVALUE, NO MINVALUE).


Modify init_params to deal with seq-options only.  This allows
AlterSequence to use it as well.


Ok, this is where it gets confusing.  Right now setval() is implemented
in such a manner that it cannot be rolled back (see SETVAL NOTE below),
but I'd like ALTER SEQUENCE to be transaction safe.   Can I assume that
a standard simple_heap_update() is valid against the sequence, so long
as I set xmin = FrozenTransactionId and create 2 XLog records similarly
to DefineSequence?

Now, do I need to do anything to clear the cache of other backends, or
simply let them play themselves out. I'm leaning towards the latter, as
nextval() appears to read in the min / max value from the sequence
buffer.


A transaction safe alter sequence, implemented in the standard method,
will result in two tuples.  Doing this many times could make sequences
quite slow.  It looks like read_info() depends on a single value value
in the sequence table.  Do I need to do something more complex like a
relfileswap, generating a fresh tuple for it -- all parts of
DefineSequence() except the DefineRelation() step? 


Anyway, I'll fiddle with the above two approaches, but would appreciate
input where appropriate.


-- SETVAL NOTE --
a=# select nextval('test');
 nextval 
-
   2
(1 row)

a=# begin;
BEGIN
a=# select setval('test', 50);
 setval 

 50
(1 row)

a=# select nextval('test');
 nextval 
-
  51
(1 row)

a=# rollback;
ROLLBACK
a=# select nextval('test');
 nextval 
-
  52
(1 row)





-- 
Rod Taylor [EMAIL PROTECTED]

PGP Key: http://www.rbt.ca/rbtpub.asc



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

Re: [HACKERS] DB Tuning Notes for comment...

[Tom Lane]

Robert Treat [EMAIL PROTECTED] writes:
 On Sun, 2002-12-08 at 09:41, Philip Warner wrote:
 First of all, the free space manager is useless at managing free space if 
 it can not map all relations (including system relations and toast 
 relations). The following query should give the correct ballpark:
 
 select count(*) from pg_class where not relkind in ('i','v');

FSM entries aren't needed for sequences either, so more correct is

select count(*) from pg_class where relkind in ('r', 't');

 It should be noted that if you have multiple databases, you'll need to
 get the number of relations minus the system tables for each database,
 then add in the number of system tables.

You're assuming that system tables are shared, which they mostly aren't.
Summing the pg_class count over all databases (or all that get vacuumed,
anyway; you can exclude template0) will be close enough.

BTW, this neglects what seems possibly an important factor: you don't
need FSM entries for tables that are effectively read-only or insert-only
(no deletes or updates).  At least in some database designs, that's a
significant number of tables.

However, I suspect that the present FSM code is not very effective at
deciding *which* tables to track if it has too few slots, so Philip's
advice of make sure there's one for every table may be the best in the
near term.  But we need to work at improving that logic.

I have some uncommitted patches concerning the FSM management heuristics
from Stephen Marshall, which I deemed too late/risky for 7.3, but we
should get something done for 7.4.  Anyone interested in playing around
in this area?

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] DB Tuning Notes for comment...

[Tom Lane]

Scott Shattuck [EMAIL PROTECTED] writes:
 Robert Treat wrote:
 I don't think this is entirely true. On tables that have large numbers
 of inserts, but no updates or deletes, you do not need to run vacuum.

 In my experience I've seen tables with numerous indexes continue to 
 benefit greatly from vacuum/vacuum full operations when large volumes of 
 inserts are performed. This is true even when the update/delete activity 
 on the base table itself is manageable.

This is hard to believe, as VACUUM does not even touch the indexes
unless it has found deletable tuples --- and I am quite certain that
btree indexes, at least, do not do any VACUUM-time reorganization beyond
deleting deletable entries.  (I wouldn't swear to it one way or the
other for GiST though.)  Robert's opinion coincides with what I know of
the code.

regards, tom lane

---(end of broadcast)---
TIP 3: 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] Sequence Cleanup

[Tom Lane]

Rod Taylor [EMAIL PROTECTED] writes:
 I'd like ALTER SEQUENCE to be transaction safe.

I think that's inherently impossible without breaking the existing
behavior of setval/nextval, which is something we will not accept.
ALTER SEQUENCE would be better thought of as a form of setval with
even more parameters, but not fundamentally different semantics.

 Can I assume that
 a standard simple_heap_update() is valid against the sequence,

You can be certain that it is not.  There can be only one tuple in a
sequence table.

regards, tom lane

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

http://archives.postgresql.org

[HACKERS] Yahoo hosting service using MySQL

[Ned Lilly]

http://webhosting.yahoo.com/ps/wh/prod/p3.html

MySQL® is considered the most popular open source database in the world. Fast and 
powerful, it is perfect for high-traffic, heavy-load sites.


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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] DB Tuning Notes for comment...

[Scott Shattuck]

Tom Lane wrote:

Scott Shattuck [EMAIL PROTECTED] writes:


Robert Treat wrote:


I don't think this is entirely true. On tables that have large numbers
of inserts, but no updates or deletes, you do not need to run vacuum.





In my experience I've seen tables with numerous indexes continue to 
benefit greatly from vacuum/vacuum full operations when large volumes of 
inserts are performed. This is true even when the update/delete activity 
on the base table itself is manageable.


This is hard to believe, as VACUUM does not even touch the indexes
unless it has found deletable tuples --- and I am quite certain that
btree indexes, at least, do not do any VACUUM-time reorganization beyond
deleting deletable entries.  (I wouldn't swear to it one way or the
other for GiST though.)  Robert's opinion coincides with what I know of
the code.



Willing to learn here but skipping a vacuum full has caused some issues 
for us. Here's some data from a recent 3 day test run that was done with 
regular vacuums but not vacuum fulls. When running with vacuum full the 
indexes remain in line:

nsuite-10=# select relname, relpages, reltuples from pg_class where 
relname not like 'pg_%' order by reltuples desc;
-[ RECORD 1 ]--
relname   | directory_fullpath_ix
relpages  | 96012
reltuples | 1.38114e+06
-[ RECORD 2 ]--
relname   | directory_pkey
relpages  | 16618
reltuples | 1.38114e+06
-[ RECORD 3 ]--
relname   | directory
relpages  | 23924
reltuples | 59578
snip

Needless to say, the system performance was pathetic but the test did 
serve to highlight this index issue.

Anyone want to give a quick summary of index maintenance or give me a 
pointer into the codebase where someone who's not a C expert might still 
get a sense of what's being done? I'd really like to understand how an 
index can get so completely out of whack after a weekend of testing.

It seems you're telling me that the data here proves there's an update 
or delete going on somewhere in the system, even though this test is of 
a database initialization driven by a stored procedure with no update or 
delete operations targeting the directory table. There may be some 
operations being done external to that process that I've not been made 
aware of but I'm still curious to learn more about indexing behavior so 
I know why something like this happens in the first place.


ss





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

Re: [PATCHES] [HACKERS] Patch to make Turks happy.

[Bruce Momjian]

Thanks.   Applied for 7.3.1.

---

Peter Eisentraut wrote:
 Bruce Momjian writes:
 
  Peter, is that patch OK for 7.3.1?  I am not sure.
 
 Definitely.  It's a bug fix.
 
 -- 
 Peter Eisentraut   [EMAIL PROTECTED]
 
 
 ---(end of broadcast)---
 TIP 2: you can get off all lists at once with the unregister command
 (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

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

Re: [HACKERS] IPv6 patch rejected

[Bruce Momjian]

I didn't read my email this weekend, so I am sorry to be late getting
back to you on this.

First, let me say I am excited about this patch.  Several people have
asked for IPv6 support, but you are the first person to actually submit
a patch for it.

I want to comment on the patch a bit because IPv6 is usually a difficult
feature to add, considering the many platforms we support.

First, I am running BSD/OS, so I have the bind 8.2.3 Inet routines in my
libc.  However, I do not have IPv6 enabled in my kernel.  Your patch
will have to deal with such systems, _and_ platforms that don't support
IPv6 at all.

It appears the patch does a few things:

changes comparison of port-raddr.sa.sa_family == AF_INET to
call to a new function isAF_INETx
changes inet_aton() call to a new function SockAddr_pton()
extensively modifies StreamServerPort
adds modifies StreamServerPortSubAFUNIX1/2
modifies connectDBStart


To better integrate your patch, I have:

reformatted to fit our coding style
renamed file v6utils.c to ipv6.c
removed 'configure' link code to use Makefile link
like md5.c
added code to create IPv4 port if IPv6 port creation fails

I need to continue reviewing the code and add a configure test to
determine if IPv6 can compile on the machine.  The fallback to IPv4
should be fine on machines that don't have IPv6 in their kernels.

The current patch can be downloaded from:

ftp://candle.pha.pa.us/pub/postgresql/mypatches/ipv6

---

Nigel Kukard wrote:
 Hrmmm,
 
 Is the compiling or running of postgresql a problem?
 
 if its the compiling we could add #ifdef's maybe to check
 if we have INET6 support... or even add it to the configure.in,
 if its running of postgresql which is the problem i have no clue
 how to get around that.
 
 
 thoughts?
 
 
 On Fri, 6 Dec 2002, Bruce Momjian wrote:
 
  
  I now have the INETv6 patch working using IPv4 on my machine, and I
  don't have IPv6 enabled in my kernel.  Tomorrow, I will review the
  entire patch for portability issues, then post it so others can test it.
  I am pretty sure it is going to fail if your machine isn't INET6 aware,
  which may be many.
  
  ---
  
The INETv6 patch was rejected because of this report, and an error on
postmaster startup from BSD/OS:

LOG:  FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor
servname provided, or not known

Please submit a new patch that addresses these issues.  I can work with
you to do testing.

---

Joe Conway wrote:
 Bruce Momjian wrote:
  Fixing now.  This just isn't my night --- another patch with a missing
  file.
  
 
 OK - I can run configure and make now, but I'm getting these warnings:
 
 In file included from ../../../../src/include/libpq/libpq.h:22,
   from printtup.c:20:
 ../../../../src/include/libpq/v6util.h:3: warning: `struct addrinfo' 
declared 
 inside parameter list
 ../../../../src/include/libpq/v6util.h:3: warning: its scope is only this 
 definition or declaration, which is probably not what you want.
 ../../../../src/include/libpq/v6util.h:5: warning: `struct addrinfo' 
declared 
 inside parameter list
 
 lots of similar warnings to the above -- and:
 
 auth.c: In function `ClientAuthentication':
 auth.c:414: warning: passing arg 1 of `isAF_INETx' from incompatible pointer 
type
 gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations 
 -I../../../src/include   -c -o crypt.o crypt.c -MMD
 In file included from ../../../src/include/libpq/libpq.h:22,
   from crypt.c:24:
 
 Joe
 
 
 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
 


   
   -- 
   
   
   Nigel Kukard  (Chief Executive Officer)
   Lando Technologies Africa (Pty) Ltd
   [EMAIL PROTECTED]   www.lando.co.za
   Tel: 083 399 5822  Fax: 086 1100036
   Hoheisen Park Bellville,  Cape Town
   National  Internet Service Provider
   
   
 The best language to use is the language that was designed for
what you want to use it for - 1997
   
   
   =
   
   Disclaimer
   --
   The contents of this message and any attachments are intended 
   solely for the addressee's use and may be legally privileged and/or 
   confidential information. This message may not be retained, 
   distributed, copied or used if you are not he addressee of this 
   message. If this message was sent to you in error, please 

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces

[Marc G. Fournier]

On Fri, 6 Dec 2002, Thomas O'Connell wrote:

 I was surprised, for instance, to receive a non-list email announcing
 the release of the software but then to have to wait for days actually
 to see it show up on the official (or even the advocacy) website in a
 news item. Even now it is not listed at PostgreSQL, Inc.

ack, an oversight, I can assure you ... I have proded the apporpriate ppl
for this one :(


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

http://archives.postgresql.org

Re: [HACKERS] DB Tuning Notes for comment...

[Tom Lane]

Scott Shattuck [EMAIL PROTECTED] writes:
 Willing to learn here but skipping a vacuum full has caused some issues 
 for us. Here's some data from a recent 3 day test run that was done with 
 regular vacuums but not vacuum fulls. When running with vacuum full the 
 indexes remain in line:

 nsuite-10=# select relname, relpages, reltuples from pg_class where 
 relname not like 'pg_%' order by reltuples desc;
 -[ RECORD 1 ]--
 relname   | directory_fullpath_ix
 relpages  | 96012
 reltuples | 1.38114e+06
 -[ RECORD 2 ]--
 relname   | directory_pkey
 relpages  | 16618
 reltuples | 1.38114e+06
 -[ RECORD 3 ]--
 relname   | directory
 relpages  | 23924
 reltuples | 59578
 snip

blink There's no way that the index and table tuple counts should
get that far out of line; in the absence of any concurrent updates,
they should be *equal* (or index  table, if you have a partial index,
which I assume these are not).  I would credit the recorded index count
exceeding the recorded table count by the number of tuples inserted/
updated while a (plain) VACUUM is in process on that table --- but this
doesn't look like it meets that situation.

There was a bug a long time ago wherein vacuum would forget to update
pg_class.reltuples for indexes in some cases, but according to the CVS
logs that was fixed before 7.2 release.  What version are you running
exactly?

In any case, you seem to be dealing with some kind of bug here.  It
might be helpful to look at the output of vacuum verbose directory
if you still have it available.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] SIGSEGV

[Patrick Welche]

Using cvs source of Dec 4 15:13:

test=# \d amount
   Table public.amount
 Column |  Type   |   Modifiers
+-+
 id | integer | not null default nextval('public.amount_id_seq'::text)
 value  | integer | 

test=# select value from amount;
 value 
---
(0 rows)

test=# select value from amount;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#


Not very graceful... (and this is different to the geqo prob I saw with my
libpq++ program, cured with geqo=false (Thanks Tom!))

Program received signal SIGSEGV, Segmentation fault.
transformTargetEntry (pstate=0x82e235c, node=0x82e21fc, expr=0x0, colname=0x0, 
resjunk=0 '\000') at parse_target.c:61
61  if (IsA(expr, RangeVar))
(gdb) bt
#0  transformTargetEntry (pstate=0x82e235c, node=0x82e21fc, expr=0x0, 
colname=0x0, resjunk=0 '\000') at parse_target.c:61
#1  0x80c2af0 in transformTargetList (pstate=0x82e235c, targetlist=0x82e2234)
at parse_target.c:192
#2  0x80a9c00 in transformSelectStmt (pstate=0x82e235c, stmt=0x82e22b4)
at analyze.c:1654
#3  0x80a7feb in transformStmt (pstate=0x82e235c, parseTree=0x82e22b4, 
extras_before=0xbfbfa9b0, extras_after=0xbfbfa9b4) at analyze.c:308
#4  0x80a7bd0 in parse_analyze (parseTree=0x82e22b4, parentParseState=0x0)
at analyze.c:147
#5  0x813e1c0 in pg_analyze_and_rewrite (parsetree=0x82e22b4) at postgres.c:408
#6  0x813e4a3 in pg_exec_query_string (query_string=0x82e201c, dest=Remote, 
parse_context=0x828c8ac) at postgres.c:696
#7  0x813f935 in PostgresMain (argc=5, argv=0xbfbfaca8, 
username=0x826a925 prlw1) at postgres.c:2016
#8  0x8124332 in DoBackend (port=0x826a800) at postmaster.c:2293
#9  0x8123c25 in BackendStartup (port=0x826a800) at postmaster.c:1915
#10 0x8122e0b in ServerLoop () at postmaster.c:1002
#11 0x8122972 in PostmasterMain (argc=3, argv=0x8266030) at postmaster.c:781
#12 0x80fb135 in main (argc=3, argv=0xbfbfb4b4) at main.c:209
#13 0x8069e84 in ___start ()

Cheers,

Patrick

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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] DB Tuning Notes for comment...

[Philip Warner]

At 03:54 PM 9/12/2002 -0500, Tom Lane wrote:

However, I suspect that the present FSM code is not very effective at
deciding *which* tables to track if it has too few slots,


You are definitely right there.

I think it would be worth looking at removing max_fsm_tables as a tuning 
option, and adding a 'relhasfsm' flag to pg_class for those tables that 
should not be mapped. Default to 't'. Then, make the table grow dynamically 
as tables are added, or when a VACUUM occurs...

AFAICT, the only justification for a smaller list of relations is for those 
that are *almost never* subject to deletes or updates. They are certainly 
common in DB design, but I'd let the DBA designate them.

Does this sound reasonable?




Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


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

Re: [HACKERS] DB Tuning Notes for comment...

[Philip Warner]

At 02:46 PM 9/12/2002 -0500, Robert Treat wrote:

getting this info into the standard documentation and/or Bruce's tuning
guide.


I'd vote for the standard docs since it is sufficiently basic as to be 
needed by most users. We either need a tuning chapter or a new section in 
runtime configuration.




Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] DB Tuning Notes for comment...

[Tom Lane]

Philip Warner [EMAIL PROTECTED] writes:
 I think it would be worth looking at removing max_fsm_tables as a tuning 
 option, and adding a 'relhasfsm' flag to pg_class for those tables that 
 should not be mapped. Default to 't'. Then, make the table grow dynamically 
 as tables are added, or when a VACUUM occurs...

If we could make the table grow dynamically then there'd not be much
need for the config parameters at all.  The real problem is to fit into
a shmem segment whose size has to be frozen at postmaster start (which,
not incidentally, is before we've ever looked at the database...).  We
could make the constraint be on total space for relation entries + page
entries rather than either individually, but I think that'd mostly make
it harder to interpret the config setting rather than offer any real
ease of administration.

 AFAICT, the only justification for a smaller list of relations is for those 
 that are *almost never* subject to deletes or updates. They are certainly 
 common in DB design, but I'd let the DBA designate them.

It doesn't seem to me to be that hard for the system to recognize them
automatically.  Basically, if there are no holes of useful size in the
table, there's no need to create an FSM entry for it.  The trick is
useful size here --- but VACUUM already does the work needed to
estimate an average tuple size, so I'd think it could do a reasonably
good job of realizing that all the available holes are just leftover
space.  (The relation's very last page is also a special case that's
likely not special-cased correctly at the moment: perhaps it should never
be entered in FSM at all, certainly not if it's the only page that would
be entered.)

regards, tom lane

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

http://archives.postgresql.org

Re: [HACKERS] SIGSEGV

[Tom Lane]

Patrick Welche [EMAIL PROTECTED] writes:
 test=# select value from amount;
 server closed the connection unexpectedly

This is a known bug also (in the domain-constraint patch, which has
turned VALUE into a reserved word, a rather unpleasant price to pay
for the feature IMHO).  Rod claimed his latest patch fixes it, but
AFAIK that hasn't been applied yet.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] SIGSEGV

[Rod Taylor]

On Mon, 2002-12-09 at 19:04, Tom Lane wrote:
 Patrick Welche [EMAIL PROTECTED] writes:
  test=# select value from amount;
  server closed the connection unexpectedly
 
 This is a known bug also (in the domain-constraint patch, which has
 turned VALUE into a reserved word, a rather unpleasant price to pay
 for the feature IMHO).  Rod claimed his latest patch fixes it, but
 AFAIK that hasn't been applied yet.

It was applied a couple of days ago by Bruce.

a=# select value;
ERROR:  VALUE is not allowed in expression for node 732

Error message isn't great, but it doesn't crash anymore.

-- 
Rod Taylor [EMAIL PROTECTED]

PGP Key: http://www.rbt.ca/rbtpub.asc



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

Re: [HACKERS] DB Tuning Notes for comment...

[Philip Warner]

At 03:54 PM 9/12/2002 -0500, Tom Lane wrote:

FSM entries aren't needed for sequences either, so more correct is

select count(*) from pg_class where relkind in ('r', 't');


presumably:

 select count(*) from pg_class where relkind in ('r', 't', 'i');



Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Lamar Owen]

On Monday 09 December 2002 12:50, Peter Eisentraut wrote:
 Compare the 7.3 release notes, written for the most part by Bruce
 Momjian and revised by a couple of other developers, to the press
 release, written by people who were obviously ill-informed.

If people want to see the details, let them read the release-notes themselves, 
and let it be the detail document.  A press release of the detail that the 
release notes have will not get any 'press' -- and I say that wearing my 
radio broadcaster hat, where I have personally approved or disapproved 'press 
releases' in news stories in the past.  Getting 'press' is what a 'press 
release' is all about.

So, IMHO, the pgsql-announce mailing list should get the press release along 
with the other 'outside' press outlets -- and the developers' lists (since 
hackers is far from the only one) should, IMHO again, get a copy of the 
release notes.

 And my personal favorite is this:

 Release notes:

Internationalization
   Both multibyte and locale support are now always enabled.

 Press release:

 - Supports data in many international characters sets (UNICODE,
 EUC_JP, EUC_CN, EUC_KR, JOHAB, EUC_TW, ISO 8859-1 ECMA-94, KOI8, WIN1256,
 etc...)

 That is just plain wrong.  Support for various character sets is years
 old.

It IS true that the current release supports all of these.  The blanket 
'Supports' statement above quoted was not true in the blanket case until the 
'support' became default, since there were cases that this would not be true. 
Support != 'if you pass the right parameters to configure this will work', at 
least not at the press release level.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Jason Earl]

Peter Eisentraut [EMAIL PROTECTED] writes:

 Robert Treat writes:
 
  I think we've already shown why it doesn't hurt to market to the
  converted. I'll add that if you compare the 7.2 press release with the
  7.3 press release, you'll see none of the technical content was removed.
 
 Compare the 7.3 release notes, written for the most part by Bruce
 Momjian and revised by a couple of other developers, to the press
 release, written by people who were obviously ill-informed.

snip for brevity

So does this mean that you are volunteering to proofread the next
marketing announcement?  I would wager that only a PostgreSQL
developer (such as yourself) could have picked out the inconsistencies
that you were able to find.  The press release might have seemed
obviously ill-informed to you, but it seemed just fine to me, and I
can guarantee you that I am at least an order of magnitude more
informed about PostgreSQL than the average manager.

The difference between the press release and the Release Notes is the
intended audience.  The folks that the press release is aimed at
probably don't have any idea that SQL 92 is obsolete, or that
internationalization has been supported for years.  Chances are good
that they will skim over the new features entirely.

What *is* important to these people, however, are the customer
testimonials at the beginning of the press release and the list of
happy customers at the end.

Once management has read the press release they can ask their
developers to read the Release Notes.  Press releases don't supercede
Release Notes, they complement them.  The difference between the 7.3
Release Notes and the press release is that I could give the press
release to my boss.

PostgreSQL desperately needs marketing help.  In fact, at this point I
would say that PostgreSQL needs more marketing help than it needs
development work.  Technically PostgreSQL is clearly a winner, but
despite its myriad features and impressive performance PostgreSQL is
still not being deployed nearly as much as it *should* be.  The team
that has been assembled to market PostgreSQL has some fairly
impressive credentials.  They are certainly *much* better than what
you would expect considering how much they are getting paid :).

In short, if you want to help the folks writing the press releases,
then that's fine and dandy.  But if all you want to do is throw rocks
at the people doing the marketing, then that's another story
altogether.

Jason Earl

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

Re: [HACKERS] more compile warnings

[Bruce Momjian]

Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  You would think that would catch it.  My problem is that I am compiling
  with -O0, because I compile all day and I don't care about optimization.
 
 You should reconsider that.  At -O0 gcc doesn't do any flow analysis,
 and thus you lose many important warnings.  I'd recommend -O1 at least.

Yes, I will re-add -O to my flags.  When I did it I forgot it would
affect warnings.  In fact, I am now seeing a similar warning in python
that I hadn't seen before, and others probably don't see it because they
don't compile python.

FYI, -O2 adds only 2 minutes to my 13 minute test script (but increases
the cpu usage from 4 to 6 minutes).

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

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

http://archives.postgresql.org

Re: [HACKERS] DB Tuning Notes for comment...

[Tom Lane]

Philip Warner [EMAIL PROTECTED] writes:
 At 03:54 PM 9/12/2002 -0500, Tom Lane wrote:
 FSM entries aren't needed for sequences either, so more correct is
 
 select count(*) from pg_class where relkind in ('r', 't');

 presumably:

   select count(*) from pg_class where relkind in ('r', 't', 'i');

No, I meant what I said.  Indexes don't use the FSM.  (The premise of
the FSM is that one bit of free space in a table is as good as any other
bit; a premise quite incorrect for indexes.)

regards, tom lane

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

Re: [HACKERS] DB Tuning Notes for comment...

[Philip Warner]

At 07:01 PM 9/12/2002 -0500, Tom Lane wrote:

We
could make the constraint be on total space for relation entries + page
entries rather than either individually, but I think that'd mostly make
it harder to interpret the config setting rather than offer any real
ease of administration.


Perhaps doing both? And issue a warning to the logs when max_fsm_relations 
is borrowing from max_fsm_pages.

It might be that the outstanding patches address the problem, but at the 
moment the choice of which relations to include is not well made when 
max_fsm_relations of much too small. We should at least issue a warning; 
but allowing max_fsm_relations to borrow from max_fsm_pages seems like a 
good idea, since having the number too low (with 161 relations setting it 
to the default of 100) is useless.

Secondly, an empty database contains 98 tables, so the default setting of 
max_fsm_pages to 100 is way too low.

The tradeoff of losing 7 pages from the map to include another relation is 
worth it, especially if the logs contain a warning.

But perhaps the test itself is flawed and there is another problem 
resulting in this behaviour (doing vacuums twice in a row seems to make it 
use the free space, but I'd guess this is just edge behaviour of the FSM 
heuristics):

Create Table t(i serial, t text);
insert into t(t)  47K of UUEncoded jpeg file - ~47K of toast.
insert into t(t) select t from t;
...repeat 9 times...
create table t1 as select * from t limit 1;
...
create table t19 as select * from t limit 1;
create table t20(i serial, t text);
insert into t20(t) select t from t;

ie. build a lot of tables, with two big ones separated by OID (not sure if 
the last part is relevant).

select count(*) from pg_class where relkind in ('t','r');

in my case this resulted in 161, so I set max_fsm_relations to 100 (ie. not 
a borderline case, but the default setting).

I also left max_fsm_pages at 1 so that we should have space for several 
thousand rows.

Stop  start postmaster, then vacuum full to be comfortable no other 
problems occur, an look at file sizes of relation file and toast file.

Now:

delete from t where i = 128;
delete from t20 where i = 128;

vacuum;

check file sizes - no surprises, they should be unchanged.

Tue Dec 10 12:03:53 EST 2002
-rw---1 pjw  users   65536 2002-12-10 12:03 16979
-rw---1 pjw  users   65536 2002-12-10 12:03 33432
-rw---1 pjw  users67108864 2002-12-10 12:03 16982
-rw---1 pjw  users67108864 2002-12-10 12:03 33435

then do:

insert into t(t) select t from t20 limit 10;
insert into t20(t) select t from t limit 10;

and both files have grown:

Tue Dec 10 12:08:20 EST 2002
-rw---1 pjw  users   65536 2002-12-10 12:08 33432
-rw---1 pjw  users67764224 2002-12-10 12:08 33435
-rw---1 pjw  users67764224 2002-12-10 12:08 16982
-rw---1 pjw  users   65536 2002-12-10 12:08 16979

oddly (bug? edge behaviour?) doing two vacuums in a row results in the free 
space being used.



Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] DB Tuning Notes for comment...

[Philip Warner]

At 12:17 PM 10/12/2002 +1100, Philip Warner wrote:

Secondly, an empty database contains 98 tables,


Corrected based on Tom's later mail; from the FSM PoV, it contains 37 
(indices don't count). So it is exhausted when more than two DBs are created.




Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


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

Re: [HACKERS] DB Tuning Notes for comment...

[Tom Lane]

Philip Warner [EMAIL PROTECTED] writes:
 Secondly, an empty database contains 98 tables, so the default setting of 
 max_fsm_pages to 100 is way too low.

Only 37 of them need FSM entries, but still a good point; we should
probably bump it up to 1000 to be more realistic.

 oddly (bug? edge behaviour?) doing two vacuums in a row results in the free 
 space being used.

I'm on my way out the door, so no time to think about what's actually
happening in the current code, but ideally I would think that when the
FSM doesn't have enough space, it should prefer to remember info about
rels with heavy update activity (which might be approximated by rels
with lots of free space, but isn't really the same thing).  A VACUUM
done just after startup does not have any historical info to base this
decision on.  So it's not unreasonable for the system to make better
choices after it's been running awhile than when it's freshly booted.
I'm not sure that this is actually what's happening today, just pointing
out that I don't consider it a bug per se if the code behaves that way.
(The existing code does have some LRU effects, IIRC, but not sure
if they account for what you see.)

regards, tom lane

---(end of broadcast)---
TIP 3: 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] DB Tuning Notes for comment...

[Scott Shattuck]

Tom Lane wrote:

Scott Shattuck [EMAIL PROTECTED] writes:


Willing to learn here but skipping a vacuum full has caused some issues 
for us. Here's some data from a recent 3 day test run that was done with 
regular vacuums but not vacuum fulls. When running with vacuum full the 
indexes remain in line:



nsuite-10=# select relname, relpages, reltuples from pg_class where 
relname not like 'pg_%' order by reltuples desc;
-[ RECORD 1 ]--
relname   | directory_fullpath_ix
relpages  | 96012
reltuples | 1.38114e+06
-[ RECORD 2 ]--
relname   | directory_pkey
relpages  | 16618
reltuples | 1.38114e+06
-[ RECORD 3 ]--
relname   | directory
relpages  | 23924
reltuples | 59578
snip


blink There's no way that the index and table tuple counts should
get that far out of line; in the absence of any concurrent updates,
they should be *equal* (or index  table, if you have a partial index,
which I assume these are not).  I would credit the recorded index count
exceeding the recorded table count by the number of tuples inserted/
updated while a (plain) VACUUM is in process on that table --- but this
doesn't look like it meets that situation.

There was a bug a long time ago wherein vacuum would forget to update
pg_class.reltuples for indexes in some cases, but according to the CVS
logs that was fixed before 7.2 release.  What version are you running
exactly?


test=# select version();
   version
-
 PostgreSQL 7.2.2 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)

test=#



In any case, you seem to be dealing with some kind of bug here.  It
might be helpful to look at the output of vacuum verbose directory
if you still have it available.




NOTICE:  --Relation directory--
NOTICE:  Index directory_pkey: Pages 15628; Tuples 4988848: Deleted 35407.
CPU 0.73s/3.00u sec elapsed 40.53 sec.

NOTICE:  Index directory_fullpath_ix: Pages 80808; Tuples 4989317: 
Deleted 35407.
CPU 4.84s/3.91u sec elapsed 275.66 sec.
NOTICE:  Removed 35407 tuples in 786 pages.
CPU 0.13s/0.11u sec elapsed 1.80 sec.
NOTICE:  Pages 80156: Changed 18, Empty 0; Tup 4988787: Vac 35407, Keep 
4977704, UnUsed 348422.
Total CPU 7.85s/7.58u sec elapsed 343.84 sec.


			regards, tom lane



Thanks for any insight you can offer here.


ss



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

Re: [HACKERS] DB Tuning Notes for comment...

[Philip Warner]

At 08:39 PM 9/12/2002 -0500, Tom Lane wrote:

A VACUUM
done just after startup does not have any historical info to base this
decision on.


The actual order is:

start
delete
vacuum;
insert - does not use free space
vacuum;
insert - does not use free space
vacuum;
vacuum;
insert - uses free space

my guess is the fact that the second vacuum has no useful statistics means 
that (somehow) it is choosing the tables with free space -- perhaps because 
they are the largest?





Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 3: 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] DB Tuning Notes for comment...

[Robert Treat]

On Mon, 09 Dec 2002 19:10:23 -0500, Tom Lane wrote:

 Philip Warner [EMAIL PROTECTED] writes:
 I think it would be worth looking at removing max_fsm_tables as a
 tuning option, and adding a 'relhasfsm' flag to pg_class for those
 tables that should not be mapped. Default to 't'. Then, make the table
 grow dynamically as tables are added, or when a VACUUM occurs...
 
 If we could make the table grow dynamically then there'd not be much
 need for the config parameters at all.  The real problem is to fit into
 a shmem segment whose size has to be frozen at postmaster start (which,
 not incidentally, is before we've ever looked at the database...).  We
 could make the constraint be on total space for relation entries + page
 entries rather than either individually, but I think that'd mostly make
 it harder to interpret the config setting rather than offer any real
 ease of administration.
 

Can we not just have vacuum of a database return a total # of pages
modified and relations modified, and then report suggested free space map
settings? Even this little bit would be a step in the right direction.

Robert Treat

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] DB Tuning Notes for comment...

[Philip Warner]

At 09:10 PM 9/12/2002 -0500, Robert Treat wrote:

Even this little bit would be a step in the right direction.


What I would find really useful is a 'VACUUM...WITH HISORY' which wrote the 
underlying details of VACUUM VERBOSE to a 'pg_vacuum_history' table.




Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] nested transactions

[Kevin Brown]

Bruce Momjian wrote:
 I am going to work on nested transactions for 7.4.
 
 My goal is to first implement nested transactions:
 
   BEGIN;
   SELECT ...
   BEGIN;
   UPDATE;
   COMMIT;
   DELETE;
   COMMIT;
 
 and later savepoints (Oracle):
 
 
   BEGIN;
   SELECT ...
   SAVEPOINT t1;
   UPDATE;
   SAVEPOINT t2;
   DELETE;
   ROLLBACK TO SAVEPOINT t2;
   COMMIT;
 
 I assume people want both.

Yep.

My question is: how do you see cursors working with nested
transactions?

Right now you can't do cursors outside of transactions.
Subtransactions would complicate things a bit:

BEGIN;
DECLARE CURSOR x ...
BEGIN
(is cursor x visible here?  What are the implications of using it if
it is?)
...
COMMIT;
...
COMMIT;


Would we only allow cursors within the innermost transactions?  If we
allow them anywhere else, why retain the requirement that they be used
within transactions at all?


-- 
Kevin Brown   [EMAIL PROTECTED]

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

http://archives.postgresql.org

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Tom Lane]

Jason Earl [EMAIL PROTECTED] writes:
 Peter Eisentraut [EMAIL PROTECTED] writes:
 Compare the 7.3 release notes, written for the most part by Bruce
 Momjian and revised by a couple of other developers, to the press
 release, written by people who were obviously ill-informed.

 So does this mean that you are volunteering to proofread the next
 marketing announcement?  I would wager that only a PostgreSQL
 developer (such as yourself) could have picked out the inconsistencies
 that you were able to find.

FWIW, the press release looked fine to me too (and yes, I saw it in
advance).

 The difference between the press release and the Release Notes is the
 intended audience.

Exactly.  The level of detail in the release notes is aimed at hackers
(and usually gets criticized as insufficient by them ;-)), but a press
release has entirely different purposes.

 In short, if you want to help the folks writing the press releases,
 then that's fine and dandy.

One error that I think the advocacy team made is that they didn't invite
review of the press release from a wider part of the community.
Although I generally agree with the viewpoint that marketing issues
should be on a separate list and not on -hackers or -general, I think it
wouldn't be out of place to send one message to those lists saying a
draft of the press release for event FOO is up at this URL, please
send comments to advocacy mail list.  That seems like a reasonable
compromise between filling the lists with unwanted material and having
people feel that they were excluded from the process.

regards, tom lane

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

http://archives.postgresql.org

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Peter Eisentraut]

Josh Berkus writes:

 I can definitely understand someone not wanting to *participate* in
 marketing/advocacy of PostgreSQL.  However, your being opposed to
 promoting PostgreSQL as an organized activity *at all* baffles me.  How
 can you be against promoting PostgreSQL?

I'm not against promoting PostgreSQL.  I'm against promoting PostgreSQL in
ways that embarrass me.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Josh Berkus]

Peter,

  I can definitely understand someone not wanting to *participate* in
  marketing/advocacy of PostgreSQL.  However, your being opposed to
  promoting PostgreSQL as an organized activity *at all* baffles me.  How
  can you be against promoting PostgreSQL?
 
 I'm not against promoting PostgreSQL.  I'm against promoting PostgreSQL in
 ways that embarrass me.

What, specifically, were you embarassed by?   

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


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

http://archives.postgresql.org

[HACKERS] psql's \d commands --- end of the line for 1-character identifiers?

[Tom Lane]

[ moved to hackers from pgsql-patches ]

Christopher Kings-Lynne [EMAIL PROTECTED] writes:
 Peter wrote:
 Christopher Kings-Lynne writes:
 \dc - list conversions [PATTERN]
 \dC - list casts
 
 What are we going to use for collations?

 \dn   Is the only letter left in collations that hasn't been used!

... and that was already proposed for show schemas (namespaces).

I'm inclined to think it's time to bite the bullet and go over to
words rather than single characters to identify the \d target
(viz, \dschema, \dcast, etc, presumably with unique abbreviations
being allowed, as well as special cases for the historical single
characters).

The issue here is what do we do with the existing \d[istvS] behavior
(for instance, \dsit means list sequences, indexes, and tables).
Is that useful enough to try to preserve, or do we just bit-bucket it?
If we do try to preserve it, how should it work?

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Sequence Cleanup

[Hannu Krosing]

Rod Taylor kirjutas T, 10.12.2002 kell 01:49:
 Below is a short list of TODOs on sequences I wish to tackle over the
 next week.
...
 Ok, this is where it gets confusing.  Right now setval() is implemented
 in such a manner that it cannot be rolled back (see SETVAL NOTE below),
 but I'd like ALTER SEQUENCE to be transaction safe.

All *val('seqname') functions are transaction-unsafe, i.e. live outside
transactions. 

Why would you want alter transaction to be transaction safe ? 


-- 
Hannu Krosing [EMAIL PROTECTED]

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

Re: [HACKERS] proposal: array utility functions phase 1

[Joe Conway]

Tom Lane wrote:

This seems fairly unworkable to me as-is.  By definition, WHERE selects
from a cross-product of the FROM tables; to make the above do what you
want, you'd have to break that fundamental semantics.  The semantics of
explicit JOIN cases would be broken too.

What we need is some kind of explicit multi-level SELECT operation.
Perhaps it would help to think about the analogy of aggregates of
aggregate functions, which are impossible to express properly in a
single SELECT but work nicely given subselect-in-FROM.
Subselect-in-FROM doesn't seem to get this job done though.

Right offhand I don't see any reasonable syntax other than
function-in-the-SELECT-list, which shoots us right back into the
messinesses of the Berkeley implementation.  However, we do now have the
precedent of the table-function AS clause.  Does it help any to do
something like

	SELECT grosysid, array_values(grolist) AS (array_index,member_id)
	FROM pg_group where groname = 'g2';


After further thought, and ignoring the difficulty of implementation, what 
seems ideal is to be able to specify 'setof datatype' or 'setof 
composite-type' as an input to the function, and fire the function once for 
each row of the input. Basically, allow anything that now qualifies as a FROM 
item -- a table reference, a subselect with AS clause, another table function, 
or maybe even a join clause. Some (totally contrived) examples of how it would 
look:

create table foo1(f1 int, f2 text);
insert into foo1 values(1,'a');
insert into foo1 values(2,'b');
insert into foo1 values(3,'c');

create table foo2(f1 int, f2 text);
insert into foo2 values(1,'w');
insert into foo2 values(1,'x');
insert into foo2 values(2,'y');
insert into foo2 values(2,'z');

create function funcfoo1(setof foo1) returns setof foo2 as 'select * from foo2 
where foo2.f1 = $1.f1' language 'sql';
select * from funcfoo1(foo1);
 f1   f2
+-
 1  | w
 1  | x
 2  | y
 2  | z

select * from funcfoo1((select * from foo1 where f1=1) as t);
 f1   f2
+-
 1  | w
 1  | x


What do you think?


(Again you could wrap this in an outer SELECT to transform the
member_ids to member_names.)

The real problem with the Berkeley approach shows up when you consider
what happens with multiple table functions called in a single SELECT.
The code we currently have produces the cross-product of the implied
rows (or at least it tries to, I seem to recall that it doesn't
necessarily get it right).  That's pretty unpleasant, and though you can
filter the rows in an outer SELECT, there's no way to optimize the
implementation into a smarter-than-nested-loop join.


What if there was a way to declare that a table function returns sorted 
results, and on which column(s)?


It seems like somehow we need a level of FROM/WHERE producing some base
rows, and then a set of table function calls to apply to each of the
base rows, and then another level of WHERE to filter the results of the
function calls (in particular to provide join conditions to identify
which rows to match up in the function outputs).  I don't see any way to
do this without inventing new SELECT clauses out of whole cloth
... unless SQL99's WITH clause helps, but I don't think it does ...


Is this still needed given my approach above?



How ugly/difficult would it be to allow the planner to interrogate the 
function and let the function report back a tupledesc based on the actual 
runtime input parameters?


Parse-time, not run-time.  It could be done --- IIRC, the auxiliary
function info call we introduced in the V1 fmgr protocol was
deliberately designed to allow expansion in this sort of direction.
But it would have to take a tupledesc (or some similar static
description) and return another one.


Nice! I'll dig in to that a bit.

Thanks,

Joe




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

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] tuple descriptors?

[Nate Sommer]

Can anyone tell me how to get a tuple's TupleDesc 
if all that is known is the tid? Or is there an easy way to step through a 
tuple, retrieving the data and data type from each field?

Thanks,
Nate Sommer

Re: [HACKERS] tuple descriptors?

[Tom Lane]

Nate Sommer [EMAIL PROTECTED] writes:
 Can anyone tell me how to get a tuple's TupleDesc if all that is known is t=
 he tid?  Or is there an easy way to step through a tuple, retrieving the da=
 ta and data type from each field?

Tupledescs are generally associated with tables (relations) more easily
than with specific tuples.  What exactly is your context here?

regards, tom lane

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

http://archives.postgresql.org

Re: [HACKERS] Let's create a release team

[Dan Langille]

On 9 Dec 2002 at 11:38, Tom Lane wrote:

 Dan Langille [EMAIL PROTECTED] writes:
  Let's create a release team.  This strategy is one well established
  in other projects and in industry.  For lack of a better starting
  reference, let me suggest http://www.freebsd.org/releng/charter.html
  as a starting point for consideration.  See also
  http://www.freebsd.org/releng/index.html.  
 
  This will also lighten the load on the core team allowing them to
  focus on development and such.  
 
 I don't really see any value-added here.  The core committee's only
 routinely-exercised function is to organize releases; separating that
 out would leave core with nothing to do.  

So we already have a release team, but not titled as such.

 Also, to the extent that
 core has any real or perceived authority in the project, I think it
 comes from having control of the release process --- there's surely no
 other reason for people to defer to the core team as a group (as
 opposed to whatever respect might be accorded to individual people as
 a result of their individual contributions).

Is the process documented?  Any set procedure?  Who knows how to do 
it?

 So ISTM such a
 reorganization would leave the core committee as a figurehead and make
 the release team into the effective new core.

Is 'core' the same as 'steering'?  I couldn't find any reference to 
core committe or core team via google.  At 
http://developer.postgresql.org/bios.php I see the group of people 
referred to as Steering.  Is their function defined anywhere?

If these things are not documented, they should be.  Where do I 
start?
-- 
Dan Langille : http://www.langille.org/


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] tuple descriptors?

[Nate Sommer]

  Can anyone tell me how to get a tuple's TupleDesc if all that is known
is t=
  he tid?  Or is there an easy way to step through a tuple, retrieving the
da=
  ta and data type from each field?

 Tupledescs are generally associated with tables (relations) more easily
 than with specific tuples.  What exactly is your context here?

 regards, tom lane

I'm a student taking a database systems course, and as a project option I
chose to work on one of PostgreSQL's todo list items, namely auto-delete
large objects when referencing row is deleted.  The main point of the
project is to become more comfortable tackling large amounts of code.
Working through the PostgreSQL code has been very interesting, and thus far
I've worked independently, but now I'm getting a little overwhelmed.  What
I'd like to do is add some code to the heap_delete function that checks the
tuple being deleted for oids, compares those oids to the loids in the
pg_largeobject relation, and deletes rows accordingly.  I thought using
TupleDescs would be helpful, but I guess my understanding of them is off.

Nate Sommer


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

Re: [HACKERS] psql's \d commands --- end of the line for 1-character identifiers?

[Christopher Kings-Lynne]

 ... and that was already proposed for show schemas (namespaces).

 I'm inclined to think it's time to bite the bullet and go over to
 words rather than single characters to identify the \d target
 (viz, \dschema, \dcast, etc, presumably with unique abbreviations
 being allowed, as well as special cases for the historical single
 characters).

Hmmm...I'm not certain that the \d commands really NEED to have a logical
link to the actual thing you're listing.  If you just made \dh for schemas,
people would look it up and then remember it from then on.  It's probably
not a huge deal.

We could do DESCRIBE commands as well.  Also, what happened to the
INFORMATION_SCHEMA proposal?  Wasn't Peter E doing something with that?
What happened to it?

 The issue here is what do we do with the existing \d[istvS] behavior
 (for instance, \dsit means list sequences, indexes, and tables).
 Is that useful enough to try to preserve, or do we just bit-bucket it?
 If we do try to preserve it, how should it work?

I'd much rather it were preserved, and I'm sure most people would as well.

Chris


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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] psql's \d commands --- end of the line for

[Hannu Krosing]

Tom Lane kirjutas T, 10.12.2002 kell 02:05:
 [ moved to hackers from pgsql-patches ]
 
 Christopher Kings-Lynne [EMAIL PROTECTED] writes:
  Peter wrote:
  Christopher Kings-Lynne writes:
  \dc - list conversions [PATTERN]
  \dC - list casts
  
  What are we going to use for collations?
 
  \dn   Is the only letter left in collations that hasn't been used!
 
 ... and that was already proposed for show schemas (namespaces).
 
 I'm inclined to think it's time to bite the bullet and go over to
 words rather than single characters to identify the \d target
 (viz, \dschema, \dcast, etc, presumably with unique abbreviations
 being allowed, as well as special cases for the historical single
 characters).
 
 The issue here is what do we do with the existing \d[istvS] behavior
 (for instance, \dsit means list sequences, indexes, and tables).
 Is that useful enough to try to preserve, or do we just bit-bucket it?
 If we do try to preserve it, how should it work?

Why not use \D for long ids ?

Somewhat similar to -? and --help for command line.

-- 
Hannu Krosing [EMAIL PROTECTED]

---(end of broadcast)---
TIP 3: 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] Darwin/Mac OS X Startup Script

[Bruce Momjian]

Added to /contrib/start-scripts as:


PostgreSQL.darwin   StartupParameters.plist.darwin

Thanks.

---

David Wheeler wrote:
 All,
 
 I've simplified the Darwin/Mac OS X startup script I submitted earlier 
 in the year. This version has only the two files required by the Darwin 
 startup bundle design. Plus the sh script now uses Darwin-standard 
 functions to start up PostgreSQL, and it checks for the presence of a 
 variable in /etc/hostconfig, as do other Darwin startup scripts.
 
 I suggest that a new directory be created, 
 contrib/start-scripts/darwin, and that these two files be put into it. 
 Folks who want to use the script can read the comments inside it to 
 figure out how to use it.
 
 Enjoy,
 
 David
 
 -- 
 David Wheeler AIM: dwTheory
 [EMAIL PROTECTED] ICQ: 15726394
 http://david.wheeler.net/  Yahoo!: dew7e
 Jabber: [EMAIL PROTECTED]

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 3: 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

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

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

Re: [HACKERS] Let's create a release team

[Justin Clift]

Hi Dan,

It's been mentioned a few times on the Advocacy and Marketing list that 
we should put together a process for ensuring that all the parts 
necessary for a release occur properly and smoothly.

***

Source code

 - Initial packaging of the new releases' source code


Docs

 - Confirm with Peter that the Docs are 100% correct in the new source 
archive


RPM's  SRPM's

 - Co-ordinate with Lamar to have these ready before the general 
announcement?


Press Releases for the General Public (multiple languages)

 - Advocacy and Marketing guys should put together a Press Release 
intended for the General Public, and have it reviewed/confirmed by the 
Hackers before getting it ready

 - Robert (?) should arrange translation of this confirmed good Press 
Release into multiple languages


Press Release for the Technically Minded (?)

 - Advocacy and Marketing guys (?) should put together a Press Release 
intended for the Hackers and other Technically Minded folk.  Should 
definitely be reviewed for accuracy by the Hackers before releasing it


Websites

 - Ensure all of the required documentation mentions, links, release 
info, etc is put in place on the website


Mailout

 - Email the appropriate Press Releases to the General Public, and to 
the Technically Minded groups


Feedback

 - Find out what could have been done better, and figure out how to 
make it so for the next one if appropriate

***

That was just what came to mind and there's probably more.  Each part 
should probably be something that can be broken down into the necessary 
parts so that everyone can take care of the bits they're into.  I 
suppose it would be good to have this listed somewhere so that people 
can make suggestions.

Just whipped up a page listing these main points here, and everyone has 
the ability to make suggestions/edits directly onto that page:

http://advocacy.postgresql.org/documents/ReleaseProcess

Hopefully that's helpful.

:-)

Regards and best wishes,

Justin Clift

--
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
- Indira Gandhi


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] tuple descriptors?

[Tom Lane]

Nate Sommer [EMAIL PROTECTED] writes:
 Tupledescs are generally associated with tables (relations) more easily
 than with specific tuples.  What exactly is your context here?

 What I'd like to do is add some code to the heap_delete function that
 checks the tuple being deleted for oids, compares those oids to the
 loids in the pg_largeobject relation, and deletes rows accordingly.

Ah.  Well, heap_delete has trivial access to the appropriate tupledesc:
relation-rd_att (or more cleanly RelationGetDescr(relation)) gives it
to you.

Not sure how large a can of worms you wanted to open here, but some
creepy-crawlies I can finger offhand include:

* don't forget heap_update's obsoleted tuple (but only when the
  replacement tuple contains a different LO oid).
* [ extra credit ] don't forget heap_truncate.  (If you can figure out
  how to do this bit without sacrificing the fundamental performance
  advantage of heap_truncate, then you're wasting your time dealing with
  us mere mortals...)
* scanning pg_largeobject anytime someone wants to delete a tuple that
  includes an OID will be a serious performance hit, especially for
  updates on system catalogs --- it could even open the potential for
  deadlocks.  Not to mention the obvious infinite-recursion problem:
  pg_largeobject itself has an OID column.  Possibly you could finesse
  most of these issues by only doing the special processing for lo
  columns not oid columns, but that seems like a cheat.  Is there a
  better way?
* OIDs are not guaranteed unique across different system catalogs.
  Maybe there isn't a better way --- certainly deleting LO 42 because
  someone deleted pg_proc 42 wouldn't be happy-making.  Within the
  catalogs we take care to know from context which catalog an OID must
  refer to, but a trigger that works on any OID column is at risk.

You've done pretty well already to identify heap_delete as a plausible
place to hack this, though.  Soldier on ...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Let's create a release team

[Tom Lane]

Dan Langille [EMAIL PROTECTED] writes:
 Is the process documented?  Any set procedure?  Who knows how to do 
 it?

Er ... nope, nope, the core bunch ...

 Is 'core' the same as 'steering'?

Yes, the webpage takes some license here.  'core' is the most common
terminology for the-usual-suspects.  I'm not sure where 'steering'
came from, but it's the same suspects...

 If these things are not documented, they should be.

Most of the undocumented details of the release process are in the heads
of Marc Fournier and Bruce Momjian.  If either of them falls off the end
of the earth, we have worse troubles than whether we remember how to do
a release --- for example: Marc owns, runs, and pays for the
postgresql.org servers.  (Me, I just hack code, so I'm replaceable.)
But if you want to try to document the process better, there are some
details written down already (eg, src/tools/RELEASE_CHANGES) and I'm
sure Marc and Bruce would cooperate in writing down more.

regards, tom lane

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

Re: [HACKERS] Let's create a release team

[Bruce Momjian]

Tom Lane wrote:
 as a result of their individual contributions).  So ISTM such a
 reorganization would leave the core committee as a figurehead and make
 the release team into the effective new core.

I thought we were already only figureheads?  ;-)

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] tuple descriptors?

[Tom Lane]

Nate Sommer [EMAIL PROTECTED] writes:
 I'm a student taking a database systems course, and as a project option I
 chose to work on one of PostgreSQL's todo list items, namely auto-delete
 large objects when referencing row is deleted.  The main point of the
 project is to become more comfortable tackling large amounts of code.

BTW, I went to a pretty outstanding tutorial on just that topic this
past summer at OSCON: Glenn Vanderburg on Using the Source: Software
Archaeology for Users of Open Source Software
(http://conferences.oreillynet.com/cs/os2002/view/e_sess/2869)
which could be described in two seconds as don't be afraid to get
your hands dirty, and in full length as how to be effective while
doing so.

The pikers at O'Reilly seem not to have made Glenn's slides available
on-line (isn't this a direct violation of their speakers' agreement?
Mine are there...) but I'm sure Glenn would be pleased to send 'em to
you on request.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] tuple descriptors?

[Philip Warner]

At 01:56 AM 10/12/2002 -0500, Tom Lane wrote:

 but I'm sure Glenn would be pleased to send 'em to
you on request.


Do you have an email address - the O'Reilly site also seems not to have one...



Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] tuple descriptors?

[Philip Warner]

At 01:56 AM 10/12/2002 -0500, Tom Lane wrote:

 but I'm sure Glenn would be pleased to send 'em to
you on request.


I've found a link:

http://www.delphis.com/java/java.html



Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 3: 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] tuple descriptors?

[Tom Lane]

Philip Warner [EMAIL PROTECTED] writes:
 At 01:56 AM 10/12/2002 -0500, Tom Lane wrote:
 but I'm sure Glenn would be pleased to send 'em to
 you on request.

 Do you have an email address - the O'Reilly site also seems not to have one...

Hrm, you're right.  I think there was one in the hardcopy slides, but
that's not beside me at the moment.  Before we deluge Glenn with
requests, let me ask him for a URL on behalf of the group ...

regards, tom lane

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

Re: [HACKERS] psql's \d commands --- end of the line for

[Tom Lane]

Hannu Krosing [EMAIL PROTECTED] writes:
 Why not use \D for long ids ?

Seems like a fine idea to me.  (I had actually started to think of
\ssomething for show, but was just observing that that would
create conflicts against existing commands, when your message arrived.
\Dsomething works though.)

Any objections out there?

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces

[Marc G. Fournier]

On Thu, 5 Dec 2002, Tom Lane wrote:

 I tend to agree with Peter.  Not that we don't need a marketing
 presence; we do (I think Great Bridge's marketing efforts are sorely
 missed).  But the point he is making is that the pgsql mailing lists go
 to people who are generally unimpressed by marketing fluff.  And they're
 already sold on PG anyway.

 The right way to handle this next time is to generate a PR-style
 press release to send to outside contacts, but to do our more
 traditional, technically-oriented announcement on the mailing lists.

Agreed ... we tried to do 'two-in-one' on this one and it didn't quite
work out as well as it could have ... next time, we'll go with both
methods ...


---(end of broadcast)---
TIP 3: 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] [GENERAL] PostgreSQL Global Development Group Announces

[Marc G. Fournier]

On Sat, 7 Dec 2002, Vince Vielhaber wrote:

 On Wed, 4 Dec 2002, Bruce Momjian wrote:

  Peter Eisentraut wrote:
   Marc G. Fournier writes:
  
It isn't, but those working on -advocacy were asked to help come up with a
stronger release *announcement* then we've had in the past ...
  
   Consider that a failed experiment.  PostgreSQL is driven by the
   development group and, to some extent, by the existing user base.  The
   last thing we need is a marketing department in that mix.
 
  Peter, I understand your perspective, but I think you are in the
  minority on this one.

 Kinda depends who you're asking now, doesn't it?  I happen to agree with
 him, but as long as you're only going to involve a selected few in the
 opinion gathering you can pretty much get the answer you want to get.  I
 can survey 100 people and get the opposite result putting you in the
 minority.

Me, I think Peter went to the 'far left', while the press release went to
the 'far right' (or vice versa) ... i think Tom sum'd it up best that we
should have had one for each 'market' we were trying to address ...
definitely something to keep in mind and strive for for the next release
...


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

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Marc G. Fournier]

s'alright, the 'fiefdoms' are about to be nuked :)

On Thu, 5 Dec 2002, Robert Treat wrote:

 On Thu, 2002-12-05 at 03:28, Dave Page wrote:
  www is a closed group consisting of a few of us who actually do the work
  on the sites.

 This is one of the primary reasons the sites are so fractured. We have 4
 different mailing lists for website development (and I'm not counting
 advocacy as one of those) and the folks maintaining those lists seem to
 be against letting anyone into their fiefdoms.

 Robert Treat



 ---(end of broadcast)---
 TIP 2: you can get off all lists at once with the unregister command
 (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


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

http://archives.postgresql.org

Re: [HACKERS] psql's \d commands --- end of the line for

[Philip Warner]

At 05:13 PM 9/12/2002 -0500, Tom Lane wrote:

Seems like a fine idea to me.


Ditto.


\Dsomething works though.)

Any objections out there?


My only complaint here is being forced to use the 'shift' key on commands 
that will be common. I would prefer any other lower case char: \b, \j, \k , 
\m, \n,   \u, \v, and \y are available. I'd vote for \v (view), or \k 
(command). The go with:

\v schema
or
\k show schema

(I'd vote for \v).








Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Justin Clift]

Peter Eisentraut wrote:
snip

Press release:

- Supports data in many international characters sets (UNICODE, EUC_JP,
  EUC_CN, EUC_KR, JOHAB, EUC_TW, ISO 8859-1 ECMA-94, KOI8, WIN1256, etc...)

That is just plain wrong.  Support for various character sets is years
old.


Sure is.  Notice it didn't say just added or added with this release?

It just says supports.  It's to highlight the fact that it can be used 
for non-English character sets.  Sure, a whole bunch of people know 
this, but the main target of the press release is people new to 
PostgreSQL that don't.

:-)

Regards and best wishes,

Justin Clift

--
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
- Indira Gandhi


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Josh Berkus]

Peter, Robert, Jason, Vince, Justin, et al.:

First off, I'd like to ask everyone to CUT IT OUT WITH THE $^*^@** FLAMING, 
ALREADY!   People are *attacking* each other instead of disagreeing.   
Several posters seem to be taking to opportunity to say everything in the 
most insulting way possible, even when the actual source of disagreement is 
small.   Perhaps we should declare a moritorium on this topic for 48 hours to 
let everyone calm down?

In case we don't, my response:

PETER, it's obvious that the press release team would have benefitted from 
your copy-editing of the press release.You have several good points about 
places where we did not do the best possible job in the difficult task of 
translating technical notes into a form the general press would understand.  
I wrote a lot of the paragraphs you take issue with, and I don't deny that 
they could stand improvement.

Would you be willing to act as a reviewer on future press releases?  That way, 
we can get the benefit of your insight in a manner that will benefit the 
press release process.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


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

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Tom Lane]

Josh Berkus [EMAIL PROTECTED] writes:
 First off, I'd like to ask everyone to CUT IT OUT WITH THE $^*^@** FLAMING, 
 ALREADY!   People are *attacking* each other instead of disagreeing.

Amen.  This was first time 'round for the advocacy group, and it's not
surprising that there are some things they did wrong, or at least could
have done better.  Can't we discuss the matter like a group of
reasonably friendly people?  I think we all have the same end goals
in mind, so I don't see the need for unpleasantness.

regards, tom lane

---(end of broadcast)---
TIP 3: 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] psql's \d commands --- end of the line for 1-character

[Bruce Momjian]

Christopher Kings-Lynne wrote:
 We could do DESCRIBE commands as well.  Also, what happened to the
 INFORMATION_SCHEMA proposal?  Wasn't Peter E doing something with that?
 What happened to it?
 
  The issue here is what do we do with the existing \d[istvS] behavior
  (for instance, \dsit means list sequences, indexes, and tables).
  Is that useful enough to try to preserve, or do we just bit-bucket it?
  If we do try to preserve it, how should it work?
 
 I'd much rather it were preserved, and I'm sure most people would as well.

I was going to say the opposite, that it isn't needed.  Oh well.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group

[Bruce Momjian]

Tom Lane wrote:
 Josh Berkus [EMAIL PROTECTED] writes:
  First off, I'd like to ask everyone to CUT IT OUT WITH THE $^*^@** FLAMING, 
  ALREADY!   People are *attacking* each other instead of disagreeing.
 
 Amen.  This was first time 'round for the advocacy group, and it's not
 surprising that there are some things they did wrong, or at least could
 have done better.  Can't we discuss the matter like a group of
 reasonably friendly people?  I think we all have the same end goals
 in mind, so I don't see the need for unpleasantness.

Agreed.  Here's a story:

Myself and a few people wanted live animals for a manger scene on our
church lawn for Christmas. Many thought it was a bad idea, but we went
ahead anyway.  It was a huge success, but then people complained we
didn't have enough people on the lawn to greet the hundreds of visitors.

Moral of the story:  if you take risks, expect folks to complain.  And,
even if you succeed, others will complain you didn't anticipate the
success.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

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

Re: [HACKERS] psql's \d commands --- end of the line for

[Philip Warner]

At 01:22 PM 9/12/2002 -0800, Christopher Kings-Lynne wrote:

Hmmm...I'm not certain that the \d commands really NEED to have a logical
link to the actual thing you're listing.


This is the perspective a person with good memory, unlike me. In find it 
useful to be able to derive commands from common-sense rules, even if it 
means a little more typing.


We could do DESCRIBE commands as well.  Also, what happened to the


This would be fine, so long as the standard does not get in the way of 
displaying postgres-specific information (eg. function attrs).



Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


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

Re: [HACKERS] nested transactions

[Bruce Momjian]

Kevin Brown wrote:
 My question is: how do you see cursors working with nested
 transactions?
 
 Right now you can't do cursors outside of transactions.
 Subtransactions would complicate things a bit:
 
 BEGIN;
 DECLARE CURSOR x ...
 BEGIN
 (is cursor x visible here?  What are the implications of using it if
 it is?)
 ...
 COMMIT;
 ...
 COMMIT;
 
 
 Would we only allow cursors within the innermost transactions?  If we
 allow them anywhere else, why retain the requirement that they be used
 within transactions at all?

I talked to Tom and he feels it will be too hard to rollback a
subtransaction that affects cursors so we will disable use of cursors in
subtransactions, at least in the first implementation.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: 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] psql's \d commands --- end of the line for

[Alvaro Herrera]

On Tue, Dec 10, 2002 at 12:55:51PM +1100, Philip Warner wrote:
 At 01:22 PM 9/12/2002 -0800, Christopher Kings-Lynne wrote:
 Hmmm...I'm not certain that the \d commands really NEED to have a logical
 link to the actual thing you're listing.
 
 This is the perspective a person with good memory, unlike me. In find it 
 useful to be able to derive commands from common-sense rules, even if it 
 means a little more typing.

Would it work to make \d tab-completable in a way that showed both the
commands that are available and the objects they describe? e.g.

\dtab would show something like
\dt [tables]\ds [sequences] \dv [views] ...

(the way it's shown now shows what completions are available, but not
what they mean.  Also, both \d and \D should be shown in any case)

-- 
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
Los romanticos son seres que mueren de deseos de vida

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

http://archives.postgresql.org

Re: [HACKERS] psql's \d commands --- end of the line for

[Matthew T. O'Connor]

 \Dsomething works though.)
 
 Any objections out there?

 My only complaint here is being forced to use the 'shift' key on commands
 that will be common.

\dd perhaps?


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] psql's \d commands --- end of the line for

[Philip Warner]

At 01:55 AM 10/12/2002 -0300, Alvaro Herrera wrote:

\dtab would show something like
\dt [tables]\ds [sequences] \dv [views] ...

(the way it's shown now shows what completions are available, but not
what they mean.  Also, both \d and \D should be shown in any case)


This would be OK, but I'd be very happy with DESCRIBE, especially if 
tab-completion meant I could type 'DESCtabTABtabname' instead of 
'DESCRIBE TABLE name'.




Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] psql's \d commands --- end of the line for

[Tom Lane]

Philip Warner [EMAIL PROTECTED] writes:
 This would be OK, but I'd be very happy with DESCRIBE, especially if 
 tab-completion meant I could type 'DESCtabTABtabname' instead of 
 'DESCRIBE TABLE name'.

That's quicker than backslashshiftDunshifttspacename ?

I don't want to sound like I've got some kind of religious objection
to DESCRIBE, but it was just a couple of hours ago that someone was
objecting to \D because it'd require touching the shift key.  Let's
get a bit realistic on the ease-of-typing arguments here.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [ADMIN] dumpProcLangs(): handler procedure for language

[Daniel Kalchev]

I have had similar troubles, related to oid overflow. I had to modify pg_dump 
to properly cast queries that contain oids. This is against 7.1.3 source. The 
patch was hacked quickly, in order to get a corrupted database reloaded, and 
this while I was traveling in another country... so it is far from perfect but 
saved my database(s). It also fixes other oid-related troubles of pg_dump.

See attached file.

Daniel

Brian Fujito said:
  Thanks for your input--
  
  I've tried both ways:
  
  createlang/droplang from the command line as user postgres
  
  and:
  
  CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS
  '/usr/lib/pgsql/plpgsql.so' LANGUAGE 'C';
  
  CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql'
  HANDLER plpgsql_call_handler
LANCOMPILER 'PL/pgSQL';
 
  I'm using pg_dump (not pg_dumpall) on the specific database on which
  I created the language.
  
  I realize 7.0.3 is ancient (same with 7.1)... I just don't have the
  time to deal with an upgrade quite yet.  Soon enough :)  In the mean
  time, a stop-gap solution would definitely be appreciated.
  
  Thank you,
  Brian
  
  
  On Mon, 2002-12-09 at 14:28, Tom Lane wrote:
   Brian Fujito [EMAIL PROTECTED] writes:
I'm running postgres-7.0.3 on RH7.1 using RedHat RPMs.
I recently added plpgsql as a language to one of my databases, 
and now when I try to do a pg_dump, I get:
   
dumpProcLangs(): handler procedure for language plpgsql not found
   
If I drop the language, pg_dump works fine, but if I add it back (and
even if I restart postgres), I get the same error.
   
   What exactly are you doing to drop and re-add the language?  I should
   think CREATE LANGUAGE would fail if the handler proc isn't there.
   
   (Also, are you doing pg_dump or pg_dumpall?  If the latter, maybe the
   failure is occurring in a different database than the one you are
   changing.)
   
   But having said that, 7.0.3 is ancient history ... you really are
   overdue for an upgrade.  With my Red Hat fedora on, I'd say the same
   about your choice of OS version too.
   
  regards, tom lane
  
  
  
  ---(end of broadcast)---
  TIP 3: 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


*** pg_dump.c.orig  Mon Apr 15 09:45:58 2002
--- pg_dump.c   Tue Jun 25 00:23:53 2002
***
*** 2006,2012 
finfo[i].prorettype = strdup(PQgetvalue(res, i, i_prorettype));
finfo[i].retset = (strcmp(PQgetvalue(res, i, i_proretset), t) == 0);
finfo[i].nargs = atoi(PQgetvalue(res, i, i_pronargs));
!   finfo[i].lang = atoi(PQgetvalue(res, i, i_prolang));
finfo[i].usename = strdup(PQgetvalue(res, i, i_usename));
finfo[i].iscachable = (strcmp(PQgetvalue(res, i, i_iscachable), t) 
== 0);
finfo[i].isstrict = (strcmp(PQgetvalue(res, i, i_isstrict), t) == 0);
--- 2006,2012 
finfo[i].prorettype = strdup(PQgetvalue(res, i, i_prorettype));
finfo[i].retset = (strcmp(PQgetvalue(res, i, i_proretset), t) == 0);
finfo[i].nargs = atoi(PQgetvalue(res, i, i_pronargs));
!   finfo[i].lang = atooid(PQgetvalue(res, i, i_prolang));
finfo[i].usename = strdup(PQgetvalue(res, i, i_usename));
finfo[i].iscachable = (strcmp(PQgetvalue(res, i, i_iscachable), t) 
== 0);
finfo[i].isstrict = (strcmp(PQgetvalue(res, i, i_isstrict), t) == 0);
***
*** 2289,2295 
  
resetPQExpBuffer(query);
appendPQExpBuffer(query,
! SELECT Oid FROM pg_index i 
WHERE i.indisprimary AND i.indrelid = %s ,
  tblinfo[i].oid);
res2 = PQexec(g_conn, query-data);
if (!res2 || PQresultStatus(res2) != PGRES_TUPLES_OK)
--- 2289,2295 
  
resetPQExpBuffer(query);
appendPQExpBuffer(query,
! SELECT Oid FROM pg_index i 
WHERE i.indisprimary AND i.indrelid = oid(%s) ,
  tblinfo[i].oid);
res2 = PQexec(g_conn, query-data);
if (!res2 || PQresultStatus(res2) != PGRES_TUPLES_OK)
***
*** 2328,2340 
appendPQExpBuffer(query,
SELECT c.relname 
  FROM pg_index i, 
pg_class c 
! WHERE i.indrelid = 
%s
  

Re: [HACKERS] PostgreSQL 7.3 Installation on SCO

[Bruce Momjian]

It should have worked, but edit Makefile.shlib and remove that offending
export from the link line.  That may fix it.

---

Shibashish wrote:
 Dear Sir,
 
 I use SCO Open Server 5.0.5 on an intel box. Although I have installed and
 used PostgreSQL on Linux, setting it on SCO has not been successful :$
 I have downloaded the latest version ie Postgresql-7.3 I have also tried
 installing postgresql-7.1 and postgresql-7.2.3, but never succeeded.
 
 I also installed ant package for using java. I have tcl8.0, tk8.0,
  itclsh3.0 and itkwish3.0 installed in my system.
  gcc version 2.7.2.1
  Java 2 SDK, Standard Edition, v. 1.2.1
  GNU Make 3.80
 
 My configure command was as following ...
 ./configure --prefix=/data/pgsql --with-perl --with-tcl
 --with-tclconfig=/data/tcl/lib/ --with-tkconfig=/data/tk/lib/
 --with-java --without-readline --without-zlib
 
 The output has been attached as file configoutput.txt
 
 Then i give the make command. The compiling stops on an error and
 exits after some time. The output has been attached as file
 makeoutput.txt
 
 I'd be thankful to you if you can help me out sort the problem. I got your
 mail-ids from the net and came to know that you are working on the similar
 lines.
 
 Also, in the file doc/FAQ_SCO, does the section Compiling PostgreSQL 7.1
 with the UDK apply to release 7.3 of Postgresql ? I am not using UDK.
 
 Waiting for a quick response from your end. kindly inform me if you have
 already solved the problem, or whether any patch is available. Any
 documentation or url will be highly helpful.
 
 Thanking You in anticipation.
 
 with regards
 Shibashish
 
 [EMAIL PROTECTED]
 On Yahoo Messenger : shib_leo
 
 Software Engineer
 IIT Bombay, India.

Content-Description: 

[ Attachment, skipping... ]

Content-Description: 

[ Attachment, skipping... ]

Content-Description: 

[ Attachment, skipping... ]

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

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

http://www.postgresql.org/users-lounge/docs/faq.html