Re: [pgsql-it-generale] to_tsvector: errori nella configurazione italiana

2008/6/13 Giorgio Valoti <giorgio_v@mac.com>:
Ciao Giorgio,

>>> test=> select to_tsvector('italian','prova');
>>> ERROR: invalid byte sequence for encoding "UTF8": 0xc3
>>> HINT: This error can also happen if the byte sequence does not match the
>>> encoding expected by the server, which is controlled by "client_encoding".
>>>
>>
>> whereas using english works fine:
>>
>>
>>> test=> select to_tsvector('english','prova');
>>> to_tsvector
>>> -------------
>>> 'prova':1
>>> (1 row)
>>>
>>
>> Danish's fine too, but not french (same error). All the .stop files
>> (italian, french, and danish) are utf8-encoded but maybe it doesn't matter,
>> I just don't know.
>>
>> I'm using the 8.3 version with Mac OS X 10.5.3 (pg server) and Mac OS X
>> 10.4.11 (psql client).
>
>

Senza saper ne leggere e ne scrivere questo errore mi puzza di import
da sql_ascii lontano un kilometro.

Il database su cui stai operando suppongo sia UTF8.
Sarebbe interessante capire come sono caricati questi dati e
l'encoding dell'eventuale database di origine.

Ad ogni modo prova la seguente procedura.
Esporta il database di origine con pg_dump passandogli l'opzione
--encoding=UTF8.
Converti il dump in utf8 con iconv
http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html
e caricalo in un altro database creato esplicitamente in UTF8.

Se la situazione e' come immagino ti sparira' l'errore ma ti
appariranno caratteri strani, sintomo di pastrocchi a livello
encoding.

Ciao
Fede

--
(all opinions expressed are my own)
Federico Campoli
PostgreSQL Consulting -> PGHost http://www.pghost.eu

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

[pgsql-it-generale] to_tsvector: errori nella configurazione italiana

Ciao a tutti, riposto qui questa mia richiesta su pgsql-general che
non ha avuto risposta. Avendo scoperto solo ora che esiste anche una
mailing list italiana ho pensato che forse c'era qualcuno che poteva
darmi qualche suggerimento. Ho una discreta esperienza con pgsql ma
non ho mai usato la ricerca full-text per cui sono un po' perso.
Mi scuso in anticipo per non aver ritradotto il messaggio ma penso
sarà sufficientemente chiaro:

> I was looking into PostgreSQL's full-text search but when using the
> to_tsvector function with italian settings I get this error:
>
>> test=> select to_tsvector('italian','prova');
>> ERROR: invalid byte sequence for encoding "UTF8": 0xc3
>> HINT: This error can also happen if the byte sequence does not
>> match the encoding expected by the server, which is controlled by
>> "client_encoding".
>>
>
> whereas using english works fine:
>
>
>> test=> select to_tsvector('english','prova');
>> to_tsvector
>> -------------
>> 'prova':1
>> (1 row)
>>
>
> Danish's fine too, but not french (same error). All the .stop files
> (italian, french, and danish) are utf8-encoded but maybe it doesn't
> matter, I just don't know.
>
> I'm using the 8.3 version with Mac OS X 10.5.3 (pg server) and Mac
> OS X 10.4.11 (psql client).

Grazie
--
Giorgio Valoti

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

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

Bruce Momjian wrote:
> Josh Berkus wrote:
>> Check it out, folks:
>>
>> http://freshmeat.net/
>
> And Freshmeat has 8.3.0! I thought we were going to keep this up to
> date, and if not, we were going to remove it. Well, we are not keeping
> it up to date!
>
> Updated: Wed, Mar 5th 2008 22:40 UTC (3 months, 10 days ago)
>
Actually it seems quite messy.

The download links for the tarball etc point to 8.3.0

The branches listed have Dev as 8.0.0rc1 and stable as 8.2.4

--

Shane Ambler
pgSQL (at) Sheeky (dot) Biz

Get Sheeky @ http://Sheeky.Biz

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

Re: [pgsql-advocacy] Booth Swag

On Thu, Jun 12, 2008 at 8:06 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> Sure, with a stitched elephant. :)
>
> They will both be embroidered. Huh, I never thought of Oxfords.

I would go for Oxfords as well. Very Dressy!

--
Regards,
Richard Broersma Jr.

Visit the Los Angles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

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

Re: [PHP] newbie issues with PDO / stored procedures

On Thu, 2008-06-12 at 05:46 -0400, pg 043g9j2g wrote:
> Hi! I am new to PHP and Postgres; in the early stages of creating a web
> app, just trying to achieve rudimentary results, yet trying to follow
> "best practices" -- in the form of using Stored Procedures vs. Dynamic
> SQL -- as I do hope to take it live to the scary ol' Internet one day.
>
> I have a stored procedure (function), "select_user_details", of the form
> "SELECT * FROM users;" which returns "SETOF users".
>
> When I execute my prepared statement, "SELECT
> select_user_details([userid])" via PDO, I get a rowset back which holds
> all the columns of users as an array in one column. From my experiement
> directly in pgAdmin Query tool, I guess that's what you expect when you
> return SETOF, but I already miss the simple DSQL I had set up where I
> could access returned columns via $row[columname] syntax.
>
> I messed around with using fetch() but that didn't seem right (more on
> that below). Then I took a look at fetchColumn() but I didn't like that
> because you address columns by index # instead of column name. Also the
> fact that you advance the row pointer with every call to any kind of
> fetch*() seems like it isn't well suited to retrieving data from more
> than one column.
>
> Now it looks like my best option in hopes of being able to access
> columns by semantically sensible names is to fetchObject() into PHP
> objects representing my database business objects. Is this correct?
> Suggestions? Alternatives? Insights?

I'm not sure this will work in your case, but the normal way to get
SETOF returning functions to return rows that look just like real table
rows is to define a view with the semantically sensible names and then
do your query against the view.

CREATE VIEW my_rows AS SELECT col1, col2, col3
FROM setof_returning_function();

Then you will get a normal select output in your program and be able to
refer to $row->col1 etc.

This doesn't necessarily work so well when you want to hand in a
parameter, unless you can hand that in by doing a join of some kind:

CREATE VIEW my_rows AS SELECT col1, col2, col3,
jointable.pkey_col AS other_key
FROM setof_returning_function(jointable.somecol), jointable;

Then you would need to do something like:

SELECT col1 FROM my_rows WHERE other_key = 75

Etc.

Hope this helps,
Andrew.

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/

PHYS: Level 6, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
It is truth which you cannot contradict; you can without any difficulty
contradict Socrates. - Plato

-------------------------------------------------------------------------

Re: [PATCHES] Tentative patch for making DROP put dependency info in DETAIL

On Thu, Jun 12, 2008 at 5:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So that's leading me to lean towards keeping RemoveRelation
> et al where they are and distributing the work currently done in
> ProcessUtility out to them. This sounds duplicative, but about all that
> really is there to duplicate is a foreach loop, which you're going to
> need anyway if the routines are to handle multiple objects.

Ok Here it is:
-Moves CheckDropPermissions and friends from utility.c to aclchk.c
(pg_drop_permission_check)

-Makes all the Remove* functions take a DropStmt *, they each do their
own foreach() loop and permission checks

-removed RemoveView and RemoveIndex because they were exactly the same
as RemoveRelation

-added an "s" to the end of the Remove* functions to denote they may
remove more than one (i.e. RemoveRelations)

-consolidated RemoveType and RemoveDomain into a common function
(static void removeHelper())

-made performMultipleDeletions when we only have one item we are
deleting log the same way (with the object name)

src/backend/catalog/aclchk.c | 154 +++++++++++++++
src/backend/catalog/dependency.c | 9 +-
src/backend/catalog/pg_conversion.c | 54 ++++---
src/backend/commands/conversioncmds.c | 45 +++--
src/backend/commands/indexcmds.c | 27 ---
src/backend/commands/schemacmds.c | 91 +++++----
src/backend/commands/tablecmds.c | 66 ++++++-
src/backend/commands/tsearchcmds.c | 290 +++++++++++++++++------------
src/backend/commands/typecmds.c | 189 ++++++++-----------
src/backend/commands/view.c | 23 ---
src/backend/tcop/utility.c | 288 +++++------------------------
src/include/catalog/pg_conversion_fn.h | 2 +-
src/include/commands/conversioncmds.h | 3 +-
src/include/commands/defrem.h | 14 +-
src/include/commands/schemacmds.h | 2 +-
src/include/commands/tablecmds.h | 2 +-
src/include/commands/typecmds.h | 4 +-
src/include/commands/view.h | 2 +-
src/include/utils/acl.h | 1 +
src/test/regress/expected/foreign_key.out | 11 -
src/test/regress/expected/truncate.out | 6 -
21 files changed, 645 insertions(+), 638 deletions(-)

[PATCHES] small typo in DTrace docs

Hi,

Attached is a small patch to fix some typos in probes.d path.

--
Euler Taveira de Oliveira

http://www.timbira.com/

Re: [HACKERS] default client encoding in postgresql.conf

Robert Treat wrote:
>> This conversation is beginning to suggest to me that client_encoding
>> shouldn't be listed in postgresql.conf at all.
>>
>>
>
> Yeah, that sure seems better than what we currently have.
>
>

I should have thought there was a good argument for preventing its being
set in postgresql.conf.

cheers

andrew

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

Re: [pgsql-advocacy] [Cert] Online or paperwork - results

On Thu, 2008-06-12 at 23:09 -0400, Greg Smith wrote:
> On Fri, 13 Jun 2008, Greg Sabino Mullane wrote:

> > 5) MySQL has a billion dollars, is installed everywhere, has pluggable
> > engines, a mountain of books, great press, lots of smart Sun developers,
> > and tons of web 2.0 companies behind it. Postgres has Tom Lane.
> > How do we level the playing field?
>
> Barrage the lists with people demanding optimizer hints.

packages

>
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
>

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

Re: [pgsql-advocacy] Booth Swag

On Thursday 12 June 2008 22:44:59 David Fetter wrote:
> On Thu, Jun 12, 2008 at 10:18:39AM -0700, Joshua D. Drake wrote:
> > On Thu, 2008-06-12 at 09:58 -0700, Josh Berkus wrote:
> > > Josh,
> > >
> > > Actually, I don't think that the USB sticks will generate much donation
> > > revenue that we wouldn't have already gotten through pins and t-shirts.
> > > I'd say an extra $100 per conference, tops.
> > >
> > > That doesn't mean they're not worth it.
> >
> > Hmm to me it does. At least in comparison to other things. If we
> > really think we can't get good donations for USB sticks, I question
> > the expense. Especially when (as you say and are correct) we already
> > generate good donations, and feedback from other less expensive but
> > equally useful items.
> >
> > For example, it may make more sense to get some collared shirts
> > instead.
>
> Polos or Oxfords?
>

Rugby style.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

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

Re: [pgsql-advocacy] [Cert] Online or paperwork - results

On Fri, 13 Jun 2008, Greg Sabino Mullane wrote:

> 1) What value between 99 and 101 should you set default_statistics_target to?

1000 unless you have some little toy database; why fool around?

> 2) Your queries are running slow, what do you do?

Blame the storage vendor.

> 3) Your database just got erased, and you need a new one. You reach for:

A scapegoat.

> 4) The best way to edit the postgresql.conf file is with:

sed

> 5) MySQL has a billion dollars, is installed everywhere, has pluggable
> engines, a mountain of books, great press, lots of smart Sun developers,
> and tons of web 2.0 companies behind it. Postgres has Tom Lane.
> How do we level the playing field?

Barrage the lists with people demanding optimizer hints.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

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

Re: [pgsql-advocacy] Booth Swag

On Thu, 2008-06-12 at 19:58 -0700, David Fetter wrote:
> On Thu, Jun 12, 2008 at 07:52:54PM -0700, Joshua D. Drake wrote:
> > On Thu, 2008-06-12 at 19:44 -0700, David Fetter wrote:
> > > Polos or Oxfords?
> >
> > Polos. Would you want an Oxford?
>
> Sure, with a stitched elephant. :)

They will both be embroidered. Huh, I never thought of Oxfords.

Joshua D. Drake

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

[COMMITTERS] pgsql: Improve the various elog messages in tuptoaster.c to report which

Log Message:
-----------
Improve the various elog messages in tuptoaster.c to report which TOAST table
the problem happened in. These are all supposedly can't-happen cases, but
when they do happen it's useful to know where.

Back-patch to 8.3, but not further because the patch doesn't apply cleanly
further back. Given the lack of response to my proposal of this, there
doesn't seem to be enough interest to justify much back-porting effort.

Tags:
----
REL8_3_STABLE

Modified Files:
--------------
pgsql/src/backend/access/heap:
tuptoaster.c (r1.81.2.2 -> r1.81.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/tuptoaster.c?r1=1.81.2.2&r2=1.81.2.3)

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

[COMMITTERS] pgsql: Improve the various elog messages in tuptoaster.c to report which

Log Message:
-----------
Improve the various elog messages in tuptoaster.c to report which TOAST table
the problem happened in. These are all supposedly can't-happen cases, but
when they do happen it's useful to know where.

Back-patch to 8.3, but not further because the patch doesn't apply cleanly
further back. Given the lack of response to my proposal of this, there
doesn't seem to be enough interest to justify much back-porting effort.

Modified Files:
--------------
pgsql/src/backend/access/heap:
tuptoaster.c (r1.87 -> r1.88)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/tuptoaster.c?r1=1.87&r2=1.88)

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

Re: [HACKERS] default client encoding in postgresql.conf

On Thursday 12 June 2008 21:11:57 Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> >>> looking in my freshly installed 8.3.3, I see this in the
> >>> postgresql.conf #client_encoding = sql_ascii # actually,
> >>> defaults to database # encoding
> >
> > But isn't putting a default that is likely to be wrong just encouraging
> > people to set it to something more permanent as an attempt to "correct"
> > this?
>
> Huh? We *aren't* putting in a default.
>

Right, but when you look in the postgresql.conf, it looks like we are setting
the default to sql_ascii (since all other default values follow this
commented setting formula).

> This conversation is beginning to suggest to me that client_encoding
> shouldn't be listed in postgresql.conf at all.
>

Yeah, that sure seems better than what we currently have.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

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

Re: [pgsql-advocacy] Booth Swag

On Thu, Jun 12, 2008 at 07:52:54PM -0700, Joshua D. Drake wrote:
> On Thu, 2008-06-12 at 19:44 -0700, David Fetter wrote:
> > On Thu, Jun 12, 2008 at 10:18:39AM -0700, Joshua D. Drake wrote:
>
> > > Hmm to me it does. At least in comparison to other things. If we
> > > really think we can't get good donations for USB sticks, I question
> > > the expense. Especially when (as you say and are correct) we already
> > > generate good donations, and feedback from other less expensive but
> > > equally useful items.
> > >
> > > For example, it may make more sense to get some collared shirts
> > > instead.
> >
> > Polos or Oxfords?
>
> Polos. Would you want an Oxford?

Sure, with a stitched elephant. :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

Re: [pgsql-advocacy] Booth Swag

On Thu, 2008-06-12 at 19:44 -0700, David Fetter wrote:
> On Thu, Jun 12, 2008 at 10:18:39AM -0700, Joshua D. Drake wrote:

> > Hmm to me it does. At least in comparison to other things. If we
> > really think we can't get good donations for USB sticks, I question
> > the expense. Especially when (as you say and are correct) we already
> > generate good donations, and feedback from other less expensive but
> > equally useful items.
> >
> > For example, it may make more sense to get some collared shirts
> > instead.
>
> Polos or Oxfords?

Polos. Would you want an Oxford?

Joshua D. Drake

>
> Cheers,
> David.

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

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

On Thu, 2008-06-12 at 22:36 -0400, Bruce Momjian wrote:
> Josh Berkus wrote:
> > Check it out, folks:
> >
> > http://freshmeat.net/
>
> And Freshmeat has 8.3.0! I thought we were going to keep this up to
> date, and if not, we were going to remove it. Well, we are not keeping
> it up to date!

It is even part of the release prep:

http://wiki.postgresql.org/wiki/ReleasePrep

We need to be checking this stuff off.

Joshua D. Drake

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

Re: [pgsql-advocacy] Booth Swag

On Thu, Jun 12, 2008 at 10:18:39AM -0700, Joshua D. Drake wrote:
>
>
> On Thu, 2008-06-12 at 09:58 -0700, Josh Berkus wrote:
> > Josh,
>
> > Actually, I don't think that the USB sticks will generate much donation
> > revenue that we wouldn't have already gotten through pins and t-shirts. I'd
> > say an extra $100 per conference, tops.
>
> > That doesn't mean they're not worth it.
> >
>
> Hmm to me it does. At least in comparison to other things. If we
> really think we can't get good donations for USB sticks, I question
> the expense. Especially when (as you say and are correct) we already
> generate good donations, and feedback from other less expensive but
> equally useful items.
>
> For example, it may make more sense to get some collared shirts
> instead.

Polos or Oxfords?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

Josh Berkus wrote:
> Check it out, folks:
>
> http://freshmeat.net/

And Freshmeat has 8.3.0! I thought we were going to keep this up to
date, and if not, we were going to remove it. Well, we are not keeping
it up to date!

Updated: Wed, Mar 5th 2008 22:40 UTC (3 months, 10 days ago)

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

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

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

Re: [pgsql-advocacy] PostgreSQL derivatives

On Thu, 2008-06-12 at 22:31 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > > And in the end, I don't see any reason for us to *turn down* sponsorship
> >
> > I do. Non-profit organisations must be run "without fear or favour" and
> > that includes not accepting gifts of any kind, though anonymous
> > donations are always acceptable.
> >
> > If we don't do this, then people may get the impression that certain
> > companies dominate and that can easily lead to non-contribution. So
> > IMHO, being even handed is critically important to our future.
>
> I am not sure how anonymous-only contributions are supposed to work.
> EnterpriseDB employs me, but no one is supposed to know that?
> EnterpriseDB sponsors a dinner at PGCon but the sponsor is a secret?

You just have the table cloth black and all the cups red. The point will
get across :P

Joshua D. Drake

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

Re: [pgsql-advocacy] [Cert] Online or paperwork - results

On Fri, 2008-06-13 at 01:39 +0000, Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160

> 1) What value between 99 and 101 should you set default_statistics_target to?
>

100

> 2) Your queries are running slow, what do you do?
>
> A) Set random_page_cost = 1 and geqo_threshold = 2;
> B) Do an ALTER TABLE SET TYPE=MYISAM; for each table in your database
> C) Blame it on the application!
> D) rm -fr the pg_xlog directory to remove those annoying WAL files
> E) Demand better hardware (and an iPhone)
> F) Run vacuum full and reindex database as a cronjob every 5 minutes
>

A & E, oh and make sure you actually vacuum analyze.

> 3) Your database just got erased, and you need a new one. You reach for:
>
> A) Your shiny Postgres CD
> B) Your snazzy Postgres thumb drive
> C) Your lovely Postgres sticker collection
> D) Your resume, to make sure it is up to date

E) Call Command PRompt

>
> 4) The best way to edit the postgresql.conf file is with:
> (wrong answers will be asked to leave the room immediately)
>
> A) emacs
> B) xemacs
> C) vi
> D) vim
> E) elvis

F) Joe

>
> 5) MySQL has a billion dollars, is installed everywhere, has pluggable
> engines, a mountain of books, great press, lots of smart Sun developers,
> and tons of web 2.0 companies behind it. Postgres has Tom Lane.
> How do we level the playing field?
>
> A) Ask Tom to take every other week off.
> B) Have him write a MySQL engine that works.
> C) Make him submit all patches in Klingon as mp3s.
>

A)

Joshua D. Drake

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

Re: [pgsql-advocacy] PostgreSQL derivatives

Simon Riggs wrote:
> > And in the end, I don't see any reason for us to *turn down* sponsorship
>
> I do. Non-profit organisations must be run "without fear or favour" and
> that includes not accepting gifts of any kind, though anonymous
> donations are always acceptable.
>
> If we don't do this, then people may get the impression that certain
> companies dominate and that can easily lead to non-contribution. So
> IMHO, being even handed is critically important to our future.

I am not sure how anonymous-only contributions are supposed to work.
EnterpriseDB employs me, but no one is supposed to know that?
EnterpriseDB sponsors a dinner at PGCon but the sponsor is a secret?

We can do anonymous-only contributions, but that is going to certainly
limit contributions. I am not sure how a company contribution will be
explained to the accounting staff if it has to be anonymous.

I think the big question is what are anonymous-only contributions trying
to solve? I have never heard of problems of favortism to contributors,
so why take a hit on contributions to avoid something no one has
reported to have happened?

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

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

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

Re: [HACKERS] Overhauling GUCS

> You guys call this "simplification"? You're out of your minds.
> This proposal is ridiculously complicated, and yet it still fails
> even to consider adjusting non-numeric parameters. And what about
> things that require more than a trivial arithmetic expression to
> compute? It's not hard at all to imagine wanting log, sqrt, etc.
>
> We do not need to put computational capability into GUC. Any
> computations needed to determine a parameter setting should be done
> by a wizard.

+1 (save the comment speculating about anyone's location relative to
their mind ;)

Additionally, obvious as it may be, there's nothing stopping anyone
from developing a tool to generate the configuration file from a
more "interesting" source. Whether that's XML or some DSL that
supports computations, doesn't matter. I would think if such a tool
showed dramatic merit it would provoke another discussion about core
integration, but ISTM that leaving it dead simple is best.

[mm, hook into the postgres startup script, shouldn't be that hard to
administer..]

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

Re: [pgsql-advocacy] [Cert] Online or paperwork - results

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> Not only first, we of course need this modules.
> I will start a discussion about this topic in the next days, but that's
> a different thread.

All this talk about process, what we need are some exam questions.
Here's some off the top of my head:

1) What value between 99 and 101 should you set default_statistics_target to?

2) Your queries are running slow, what do you do?

A) Set random_page_cost = 1 and geqo_threshold = 2;
B) Do an ALTER TABLE SET TYPE=MYISAM; for each table in your database
C) Blame it on the application!
D) rm -fr the pg_xlog directory to remove those annoying WAL files
E) Demand better hardware (and an iPhone)
F) Run vacuum full and reindex database as a cronjob every 5 minutes

3) Your database just got erased, and you need a new one. You reach for:

A) Your shiny Postgres CD
B) Your snazzy Postgres thumb drive
C) Your lovely Postgres sticker collection
D) Your resume, to make sure it is up to date

4) The best way to edit the postgresql.conf file is with:
(wrong answers will be asked to leave the room immediately)

A) emacs
B) xemacs
C) vi
D) vim
E) elvis

5) MySQL has a billion dollars, is installed everywhere, has pluggable
engines, a mountain of books, great press, lots of smart Sun developers,
and tons of web 2.0 companies behind it. Postgres has Tom Lane.
How do we level the playing field?

A) Ask Tom to take every other week off.
B) Have him write a MySQL engine that works.
C) Make him submit all patches in Klingon as mp3s.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200806122134
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkhRz2QACgkQvJuQZxSWSsiyHgCgn5k+XEG91cvlwWQGVTvT35sp
zLkAnRiaSVkqpLgKmtKhx7Yd7AcxbxvY
=Y1Of
-----END PGP SIGNATURE-----

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

Re: [pgsql-www] Proposal: pulling newsbytes from www.pgfoundry.org

On Thursday 12 June 2008 17:46:38 Josh Berkus wrote:
> > As I see it, promoting core information should be our largest priority,
> > which would include the top two items.
> >
> > our next priority should be promoting postgresql to the general
> > populations, which would include large event and pug informations.
> >
> > after that we have service level information, which is projects,
> > products, and training.
> >
> > now, I left out blogs because they are kind of across the map as far as
> > content, but based on popularity of them, they should probably be held
> > high on the list, I'd say somewhere below large event information but
> > above pugs.
>
> Hmmm. I'd put blogs lower on the list just because their content is less
> vetted.
>

right, but based on the stats, it's one of the things that draws a lot of
visitors, so I think that counts for something.

> > looking that list over, istm just aggregating pgfoundry and our current
> > news feed is the way to go, but there are still a number of areas that
> > should be addressed, imho.
>
> Which areas?

More focus on core announcements / events, regular pug promotion, highlighting
large community events, and sorting out training (which most seem to agree is
sub-optimal)

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

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

Re: [HACKERS] Overhauling GUCS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

>> Really? I'm the opposite: I never leave a client's setting at 10, that's
>> just asking for trouble. Making it 100 *after* you encounter problem
>> queries is reactive; I prefer being proactive.

> Have you ever measured the system speed before and after?

Yes. No change (see below on caching) or faster (better plans).

>> Nor is a setting of 10 "perfectly adequate":

> What percentage of your plans actually change with the larger statistics? How
> many for the better? How many were massively improved?

It matters not if there is a slight increase in planning time: the penalty
of choosing a Bad Plan far outweighs any increased analyze or planning
cost, period. Are you arguing that 10 is a good default, or just against
larger values in general?

> I suspect you're looking at some single-digit percentage slowdown for planning
> across the board. In exchange if you a) have simple queries you probably see
> none improving. If you b) have moderately complex queries you probably get
> some single-digit percentage of them with improvements. And if you c) have
> very complex queries you probably have a handful of them which see massive
> improvements. Across the internet there are a whole lot more applications of
> type (a) than the others...

I'm still skeptical that it's the case, but I wouldn't mind seeing some figures
about how slowed down a "simple" database gets going from 10 to 100 (or larger).
Robert, any chance we can use Pagila for some sort of test for that?

>> Frankly, I'd be shocked if there is any significant difference and all
>> compared to the actual query run time.

> Well you might start preparing to be shocked. Note that retrieving the
> statistics is a query itself so it's not hard for it to be comparable to a
> similarly simple query. It's not hard for a simple query using multiple
> columns to be using more records of statistics than it is from the actual
> data. And things can look much worse if that data is TOASTed and requires
> further lookups and/or decompression...

Even if all you say above is true, and I think we'll have to agree to disagree
on that, there's an important point to remember: query plans can be (and very
often are) cached. Queries and query results cannot (although I'm working
on that... :) Plans to queries is a 1-N, where N can be very, very large,
and further boosts the query time vs planning time ratio.

...
> 100 is no longer a magic threshold for LIKE queries (in CVS HEAD)

That's great, but doesn't help existing releases (unless that was backpatched,
but I don't recall it if so) But that's a battle I'm going to stop fighting,
and concentrate on helping to find a replacement for 10 that may or may not
be 100.

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200806122100
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkhRyXIACgkQvJuQZxSWSshZpwCeOdLZCu0gSQGpOLciQ6H29Tsd
iNgAn3AuoisE8zSbMjLuDL4aWzP6NAth
=ujTa
-----END PGP SIGNATURE-----

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

Re: [HACKERS] Options for protocol level cursors

On Jun 12, 2008, at 4:45 PM, Tom Lane wrote:
> Huh? I don't see why... you might have such a limitation in a
> particular driver, but not in the protocol.

Oh? I know when you bind a prepared statement you have the ability
state the formats of each column, but I'm not aware of the protocol's
capacity to reconfigure the formats of an already existing cursor; ie,
a DECLARE'd cursor. I know you can use the Describe message to learn
about the cursor's column types and formats....

Got a link to the part of the protocol docs describing this feature?

>> Also, the latter has other problems wrt statement parameters. I guess
>> you
>> could prepare(protocol level) the DECLARE, but that seems like a
>> gross
>> workaround as it defeats the purpose of prepared statements by
>> forcing
>> you
>> to create a new statement for each cursor that you plan to open.
>
> Well, using a query for a cursor is grounds for replanning anyway,
> because you might want a fast-start plan in such a case. And it's
> *definitely* grounds for replanning if you are asking for SCROLL
> capability --- the plan stored for a regular prepared statement
> very likely can't support that.

Ah, that is good to know. Thanks.

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

Re: [HACKERS] default client encoding in postgresql.conf

Robert Treat <xzilla@users.sourceforge.net> writes:
>>> looking in my freshly installed 8.3.3, I see this in the postgresql.conf
>>> #client_encoding = sql_ascii # actually, defaults to database
>>> # encoding

> But isn't putting a default that is likely to be wrong just encouraging people
> to set it to something more permanent as an attempt to "correct" this?

Huh? We *aren't* putting in a default.

This conversation is beginning to suggest to me that client_encoding
shouldn't be listed in postgresql.conf at all.

regards, tom lane

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

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

Hi,

On Thu, 2008-06-12 at 16:53 -0700, Joshua D. Drake wrote:
>
> I thought Devrim had access as well?

I have access to sf.net -- and I just finished updating it.

Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Re: [HACKERS] default client encoding in postgresql.conf

On Thursday 12 June 2008 17:38:26 Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > looking in my freshly installed 8.3.3, I see this in the postgresql.conf
> > #client_encoding = sql_ascii # actually, defaults to database
> > # encoding
> >
> > Now, certainly initdb can't know for sure what encoding a future database
> > will be in, but since it does know what encoding template0 & friends will
> > be in, and most databases are copied from those (including encoding),
> > wouldn't a better default be to set it the encoding of template0?
>
> No. Setting it at all in postgresql.conf is generally the wrong thing;
> the right thing is to let the default behavior (ie, make it equal to the
> database encoding) happen.
>

But isn't putting a default that is likely to be wrong just encouraging people
to set it to something more permanent as an attempt to "correct" this?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

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

Re: [HACKERS] Better default_statistics_target

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> That was a pretty special case (LIKE/regex estimation), and we've since
> eliminated the threshold change in the LIKE/regex estimates anyway, so
> there's no longer any reason to pick 100 as opposed to any other number.
> So we're still back at "what's a good value and why?".

Glad to hear that, although I think this is only in HEAD, not backpatched,
right? Well at any rate, I withdraw my strong support for 100 and join in
the quest for a good number. The "anything but 10" campaign.

> I'm still concerned about the fact that eqjoinsel() is O(N^2). Show me
> some measurements demonstrating that a deep nest of equijoins doesn't
> get noticeably more expensive to plan --- preferably on a datatype with
> an expensive equality operator, eg numeric --- and I'm on board.

I hope someone else on the list can do this, because I can't. :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200806122054
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkhRxToACgkQvJuQZxSWSsj0OwCfel+zN/jQth79RvIHtxpUefQD
APMAmQEKIDS6BzqUjn4eTMzP9NDlxTbE
=JZTe
-----END PGP SIGNATURE-----

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

Re: [GENERAL] file system level backup

iztech wrote:
> On Jun 12, 6:31 am, iztech <rashan...@gmail.com> wrote:
>> i have just switched to posgresql and installed for use with ruby.
>>
>> i need to move my app and database to a new server. since i can shut
>> down the server i think it will be easier for me to do a file system
>> level back up.

pg_dump and pg_restore should be just as good. If you're having trouble
manging postgresql they're probably a safer bet.

>> when i try to shut the server down i get this message
>>
>> sudo -u postgres pg_ctl -D /opt/local/var/db/postgresql82/defaultdb
>> stop
>> pg_ctl: PID file "/opt/local/var/db/postgresql82/defaultdb/
> can anyone let me know how i can tell where the db are located?

You've left out some key information, like your operating system, OS
version, postgresql version, and how you installed postgresql.

In general you should use the OS init script if provided to start and
stop postgresql. With most packaged Pg installs you can find the data
directory by examining the data_directory parameter in postgresql.conf,
which will normally be in a 'postgresql' directory under /etc .

If you hand-installed it (which looks like the case based on your
command line, above) then you should really know where the data
directory is because you had to run initdb to create it.

The -D argument on the command line above is the path to your data
directory. It's not clear whether that command is just copied & pasted
from somewhere else, because I'm a bit confused as to why you'd be
asking where the data directory was if you understood that. Check
postgresql.conf to confirm that the -D argumenet above is actually correct.

>> this is my first time attempting this. can someone suggest an easy
>> tutorial on this.

If you're new to Pg, just get the packages for your operating system if
they're reasonably recent. You can then use the OS init scripts and
normal management tools to handle Pg.

>> i have set up the new server with the same permissions so i should be
>> able to move the db to the new location.

Maybe. The version must be the same except for the patchlevel, eg
"8.2.1" is compatible with "8.2.3" but not "8.3.1". In general it is
MUCH SAFER to just use pg_dump and pg_restore to migrate your data.

--
Craig Ringer

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

Re: [pgsql-advocacy] Booth Swag

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> Well it isn't even that honestly. The cost is less than 3k USD which is
> not a big deal. The question is value to the customer. Consider that I
> can purchase a 4GB pen drive for for <20.00 USD. Why do I want a 1GB
> model? Because it has a cute elephant on it?

Yes. And because it's free. They are incredibly useful things to have
around, and I don't see anyone turning up their nose at a 1 Gigger.

> Don't get me wrong, I still think it is a positive direction in
> comparison to using CDs. I seriously think we need to completely dump
> handing out CDs. They are wasteful and *anyone* who is going to pick one
> up at OSCON or LWE or any other US show, has broadband.

Completely agree, the Age of CDs is over.

> In comparison the stickers, which are approximately the same cost as the
> CDs would be, will be seen all over the place. People will put that on
> notebooks, monitors, laptops etc... That is branding that is worth a lot
> more than a little pen drive.

+1 on the stickers, preferably with the "official alternate" spelling. :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200806122051
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkhRxHsACgkQvJuQZxSWSsgmYgCg1rYx4OZPiUNgKTwGyjMcGsMp
RmAAn0GAIM16cN2Zzc1nujQiRaquRRqQ
=sAdh
-----END PGP SIGNATURE-----

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

Re: [PATCHES] Better formatting of functions in pg_dump

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

>> Attached patch puts the "metadata" about a function, especially the
>> language name, at the top of the CREATE FUNCTION statement, above the
>> possibly long, multi-line function definition.

> Why the random switching between newline-before and newline-after
> styles? Please be consistent.

I thought they were all "after". On second glance, they still seem
all after?

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200806122044
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkhRww0ACgkQvJuQZxSWSshuQwCfYBjBLOVfJziHcyHRM4CNfCaY
gncAoK+CehREYJQdvAXfizZIPjZog4c6
=A+aR
-----END PGP SIGNATURE-----

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