Tuesday, May 27, 2008

Re: [pgsql-advocacy] swik.net is copying planetpostgresql content

On Tue, 27 May 2008 09:20:21 -0700 Joshua D. Drake wrote:
> On Tue, 2008-05-27 at 09:13 -0700, Josh Berkus wrote:
> > JD,
> >
> > > They are in my neck of the woods, possibly a nice phone call would
> > > resolve the whole issue.
> >
> > Sure. I'm just not sure there *is* an issue.
> >
>
> Well there is an issue, it just may not be a problem :). It may just be
> one of clarification.

Yeah.


> > As far as I can tell, they are just re-broadcasting *publically available RSS
> > feeds* (which is what RSS feeds are for, no?). If there is any problem (and
> > I'm not convinced there is) it's just that their copyright statement is
> > unclear.
>
> Right.

I would not name it "re-broadcasting" because of all the work they have
done to integrate the content into the wiki but basically that's it.

So i'm also +1 for politely asking.

By the way: RSS feeds are for read, not for republish the content
without permission. I granted Devrim the right to publish parts of my
blog on planetpg, but i can't remember that i or most of the other
planet posters did include the permission for other usage.


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
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-fr-generale] Drupal, CMS avec PG

Francis Leboutte a écrit :
> Merci pour ces infos utiles et d'avance pour celles concernant le réflexion PGFR.
>
> Je suis dubitatif quant à l'utilisation d'un Wiki pour certains projets, par exemple pour ceux où une certaine ligne éditoriale doit être maintenue et l'information n'est pas aussi simple à structurer que dans un projet comme Wikipédia.
>
> Ce serait intéressant de faire une comparaison point par point en fonction des besoins. Dès que j'ai un peu de temps, je ferai une recherche sur le web (EN, FR) pour voir si quelque chose n'a pas été fait sur le sujet.
>
> Cordialement,
>
> Francis

Bonjour,

Pour comparer les Wiki ou les CMS entre eux, en terme de fonctionnalités, vous
pouvez vous rendre sur wikimatrix.org et cmsmatrix.com

Bon courage :-)

Librement,
--
Stéphane SCHILDKNECHT
Président de PostgreSQLFr
Tél. 09 53 69 97 12
http://www.postgresql.fr

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

[HACKERS] Hiding undocumented enum values?

There are several GUC enums that accept values that aren't documented
anywhere; the worst offender being backslash_quote, which has more
undocumented spellings than documented ones:

/*
* Although only "on", "off", and "safe_encoding" are documented, we
* accept all the likely variants of "on" and "off".
*/
static const struct config_enum_entry backslash_quote_options[] = {
{"safe_encoding", BACKSLASH_QUOTE_SAFE_ENCODING},
{"on", BACKSLASH_QUOTE_ON},
{"off", BACKSLASH_QUOTE_OFF},
{"true", BACKSLASH_QUOTE_ON},
{"false", BACKSLASH_QUOTE_OFF},
{"yes", BACKSLASH_QUOTE_ON},
{"no", BACKSLASH_QUOTE_OFF},
{"1", BACKSLASH_QUOTE_ON},
{"0", BACKSLASH_QUOTE_OFF},
{NULL, 0}
};

I am wondering if it's a good idea to hide the redundant entries
to reduce clutter in the pg_settings display. (We could do this
by adding a "hidden" boolean to struct config_enum_entry.)
Thoughts?

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] swik.net is copying planetpostgresql content

On Tue, 2008-05-27 at 09:13 -0700, Josh Berkus wrote:
> JD,
>
> > They are in my neck of the woods, possibly a nice phone call would
> > resolve the whole issue.
>
> Sure. I'm just not sure there *is* an issue.
>

Well there is an issue, it just may not be a problem :). It may just be
one of clarification.

> As far as I can tell, they are just re-broadcasting *publically available RSS
> feeds* (which is what RSS feeds are for, no?). If there is any problem (and
> I'm not convinced there is) it's just that their copyright statement is
> unclear.

Right.

Sincerely,

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] swik.net is copying planetpostgresql content

JD,

> They are in my neck of the woods, possibly a nice phone call would
> resolve the whole issue.

Sure. I'm just not sure there *is* an issue.

As far as I can tell, they are just re-broadcasting *publically available RSS
feeds* (which is what RSS feeds are for, no?). If there is any problem (and
I'm not convinced there is) it's just that their copyright statement is
unclear.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

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

[COMMITTERS] pgsnap - pgsnap: Bugfix : on "Installed Products" report, pgsnap didn't

Log Message:
-----------
Bugfix : on "Installed Products" report, pgsnap didn't understand "unset" value, and logging_collector
was used instead of stats_start_collector for releases < 8.3.

Tags:
----
REL0_3_STABLE

Modified Files:
--------------
pgsnap/pgsnap:
ChangeLog (r1.33.2.1 -> r1.33.2.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/ChangeLog.diff?r1=1.33.2.1&r2=1.33.2.2)
pgsnap/pgsnap/lib:
ver.php (r1.8 -> r1.8.2.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/lib/ver.php.diff?r1=1.8&r2=1.8.2.1)

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

Re: [PATCHES] Doc patch: type modifiers

Jeff Davis <pgsql@j-davis.com> writes:
> From
> http://developer.postgresql.org/pgdocs/postgres/sql-createtype.html :
> type_modifier_input_function
> The name of a function that converts numeric modifier(s) for the
> type into internal form.

Yeah, this text is a holdover from the original user-definable-modifiers
patch, in which the modifiers indeed had to be numbers. I don't quite
like your suggestion of using "textual", though, because that makes it
sound like the input and output functions are exact inverses, which they
are not. How about "... converts an array of modifier(s) for ..."?

regards, tom lane

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

Re: [SQL] Enumerated (enum) types

In article <5ac667b80805270729x4f93cc14n4a868d3d3f624d7b@mail.gmail.com>,
"Michael Lourant" <lourant@gmail.com> writes:

> Type Safety

> Enumerated types are completely separate data types and may not be compared
> with each other.

...

> An Alternative Way To Do The Same

> Instead of using an enum type we can set up a CHECK CONSTRAINT - this tells
> postgresql to make sure that the value we are entering is valid.

> CREATE TABLE person (
> personid int not null primary key,
> favourite_colour varchar(255) NOT NULL,
> CHECK (favourite_colour IN ('red', 'blue', 'yellow', 'purple'))

> );

> INSERT INTO person(personid, favourite_colour) VALUES (1, 'red');
> INSERT 0 1

> Now for something not in the list:

> INSERT INTO person(personid, favourite_colour) VALUES (2, 'green');
> ERROR: new row for relation "person" violates check constraint "person_favourite_colour_check"

Type safety is the thing you lose by replacing an ENUM by a CHECK
constraint - you can still do something nonsensical like

SELECT * FROM person WHERE favourite_colour = 'green'


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

Re: [pgsql-advocacy] swik.net is copying planetpostgresql content

> The alternative is to have SWiK not include PostgreSQL at all, which is not a
> good outcome for us. I think that we *might* send them a politely worded
> request to clarify their copyright statement (I'll be happy to do this).
> Beyond that, this seems like a real non-issue.

They are in my neck of the woods, possibly a nice phone call would
resolve the whole issue.

Sincerely,

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] swik.net is copying planetpostgresql content

+1

I've said something pretty similar though, or that was my intention at least :)

gb.-

On Tue, May 27, 2008 at 1:00 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Folks,
>
> "Never attribute to malice what can be explained by stupidity or inattention."
>
> As far as I can tell, SWiK is guilty of nothing worse that sloppiness. I see
> absolutely no reason to assume that they are trying to do something sinister.
> What would be their motivation?
>
> Further, SWiK *does* link back to the original blogs. So some of the argument
> posted here has been based on false premises.
>
> The alternative is to have SWiK not include PostgreSQL at all, which is not a
> good outcome for us. I think that we *might* send them a politely worded
> request to clarify their copyright statement (I'll be happy to do this).
> Beyond that, this seems like a real non-issue.
>
> --
> Josh Berkus
> PostgreSQL @ Sun
> San Francisco
>
> --
> Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-advocacy
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@globant.com

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

Re: [ADMIN] v8.2.6->8.2.7 upgrade renamed /var/lib/pgsql

Yes, AFAIK, this machine is using the standard Fedora update repository.

I'll just chalk this up to "anomalous behaviour of unknown origin" and
add this to my test-after-updates checklist.

Thanks,

Gord


> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Sunday, May 25, 2008 7:38 PM
> To: Hyatt, Gordon
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] v8.2.6->8.2.7 upgrade renamed /var/lib/pgsql
>
> "Hyatt, Gordon" <Gordon.Hyatt@joslin.harvard.edu> writes:
> > I just applied the v8.2.7 upgrade (from v8.2.6) on and FC8 server
via
> > yum. The upgrade went OK, but the /var/lib/pgsql directory (with
the
> > existing data) was renamed to /var/lib/pgsql.old and a new (and
empty)
> > /var/lib/pgsql directory was created.
>
> That's just weird. I tried the same here (also on an x86_64 F-8 box)
> and didn't see it happen. Are you using the standard Fedora update
> repository?
>
> regards, tom lane

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

Re: [pgsql-advocacy] swik.net is copying planetpostgresql content

Folks,

"Never attribute to malice what can be explained by stupidity or inattention."

As far as I can tell, SWiK is guilty of nothing worse that sloppiness. I see
absolutely no reason to assume that they are trying to do something sinister.
What would be their motivation?

Further, SWiK *does* link back to the original blogs. So some of the argument
posted here has been based on false premises.

The alternative is to have SWiK not include PostgreSQL at all, which is not a
good outcome for us. I think that we *might* send them a politely worded
request to clarify their copyright statement (I'll be happy to do this).
Beyond that, this seems like a real non-issue.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

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

[COMMITTERS] pgsnap - pgsnap: Bugfix : default report for statistics tab should be

Log Message:
-----------
Bugfix : default report for statistics tab should be the cache hit ratio
(old one, bgwriter, is not available in releases prior to 8.3)

Tags:
----
REL0_3_STABLE

Modified Files:
--------------
pgsnap/pgsnap:
ChangeLog (r1.33 -> r1.33.2.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/ChangeLog.diff?r1=1.33&r2=1.33.2.1)
pgsnap/pgsnap/template:
header.template.html (r1.5 -> r1.5.2.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/template/header.template.html.diff?r1=1.5&r2=1.5.2.1)

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

Re: [BUGS] BUG #4203: perform dblink() in begin/exception returns wrong SQLSTATE code

"Henry Combrinck" <henry@zen.co.za> writes:
> Description: perform dblink() in begin/exception returns wrong
> SQLSTATE code

> The code returned is always 42601 (syntax_error) irrespective of the actual
> error (eg, unique_violation).

Yeah, the dblink code should probably try a bit harder to propagate the
original error fields. I'm inclined to think that it should propagate
sqlstate/message/detail/hint verbatim, and indicate the fact that this
happened on a dblink connection as CONTEXT, rather than structuring the
ereport the way it does now. Joe, what do you think?

regards, tom lane

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

Re: [pgsql-fr-generale] Drupal, CMS avec PG

Merci pour ces infos utiles et d'avance pour celles concernant le réflexion PGFR.

Je suis dubitatif quant à l'utilisation d'un Wiki pour certains projets, par exemple pour ceux où une certaine ligne éditoriale doit être maintenue et l'information n'est pas aussi simple à structurer que dans un projet comme Wikipédia.

Ce serait intéressant de faire une comparaison point par point en fonction des besoins. Dès que j'ai un peu de temps, je ferai une recherche sur le web (EN, FR) pour voir si quelque chose n'a pas été fait sur le sujet.

Cordialement,

Francis

Le 25/05/2008 20:19, damien clochard écrivait :
>Le Sunday 25 May 2008 16:29:28 Francis Leboutte, vous avez écrit :
>> Bonjour,
>>
>> En fouillant dans les archives de la liste j'ai trouvé quelques
>> commentaires sur Drupal qui est utilisé pour le site postgresqlfr.org. En
>> voici deux (datant de 2005) :
>>
>> « Alors pour faire pgfr.org j'ai opté pour Drupal, qui lui est un gros veau
>> bien lent, mais qui est relativement propre question code. »
>>
>> « Aujourd'hui, Drupal assure vraiment bien, mais est toujours un peu trop
>> lourd pour le processeur Géode que possède l'Open Brick sur lequel tourne
>> le site!! »
>>
>
>C'est un commentaire très vieux car cela fait au moins 3 ans que le site
>www.postgresqlfr.org ne tourne plus sur un processeur Geode. :-)
>
>Aujourd'hui le portail principal de postgresqlfr.org fonctionne sur un bi-pro
>3Ghz. La version de drupal que nous utilisons est une 4.7.x, c'est à dire une
>antiquité ( la version 6 vient de sortir )
>
>Une très grosse réflexion est en cours au sein de l'asso PGFR pour décider de
>l'avenir de la plate-forme. Le constat de départ est que notre version de
>drupal est obsolète. Par ailleurs après 5 ans d'existence, la masse d'
>information est tout simplement trop grande pour être gérée dans un CMS
>unique : les listes de diffusion, le wiki, la planete, la doc, ( probablement
>bientôt les forums) tout cela a fini par être hébergé en dehors de drupal.
>
>Je rédigerai un message plus détails sur ce sujet dans quelques jours.
>
>> Quant est-il de Drupal aujourd'hui ?
>
>D'après moi Drupal est un très bon CMS, très modulaire..
>
>Ce qu'on lui reproche c'est d'être extrèmement compliqué. Drupal introduit
>tout un tas de concepts ( "taxonomie", "noeud", "livre", etc. ) qu'il faut
>bien comprendre pour arriver a exploiter la puissance du logiciel.
>
>Le temps passe. Les administrateurs changent. Les connaissances se perdent.
>et si les concepts de base ont été mal transmis, on se retrouve avec une
>machine à gaz ingérable en l'espace de 3 ans.
>
>Tout ceci va l'encontre la tendance actuelle qui est de simplifier les
>interfaces (KISS !) et faciliter l'écriture pour un maximum de visiteurs des
>sites ( l'inénarrable web deux point zéro... ).
>
>Les wikis sont l'illustration parfaite de cette nouvelle tendance.
>
>Drupal , Joomla et consorts sont probablement des softs très puissants mais
>il s'avère que la simplicité est souvent plus importante que la puissance.
>
>En tout cas a titre personnel je suis convaincu que l'époque des
>gros "CMS-qui-savent-tout-faire" est révolue :-)
>
>
>> Notamment sur le point de vue performance ?
>
>Il y a deux ans environ on a vécu une augmentation de trafic . On est passsé
>de 110 000 à 170 000 pages vues par mois. Ceci a ralenti le site de manière
>significative. Après investigation on s'est rendu compte que le serveur
>PostgreSQL était bombardé de requêtes et avait du mal à suivre. La solution a
>consisté à intercaler un pooler de connexion (pgpool) entre drupal et
>postgresql...
>
>> Drupal s'est-il amélioré ?
>
>Aucune idée.
>Cédric Villemain a fait quelques recherches sur drupal 6. Peut-être qu'il
>pourra en dire plus. :-)
>
>> S'agit-il uniquement d'un problème de performance au moment de la création
>du contenu ?
>
>Non. Les données du site sont utilisées à 99,99% en lecture. La création de
>contenu n'est pas le soucis premier ;-)
>
>>
>> Quels sont les avantages et inconvénients de Drupal par rapport à SPIP,
>> très populaire en francophonie ?
>
>Je connais assez bien SPIP et à mon avis c'est une erreur de le considérer
>comme un CMS.
>SPIP est parfait pour gérer un journal en ligne, c'est à dire
>une équipe de rédacteurs , un comité de rélecture, et des droits de réponse en
>bas de chaque article.
>En dehors de cette organisation bien particulière, SPIP n'a pas beaucoup
>d'intérêt.
>
>Toute tentative de transformer SPIP en un CMS généraliste est une perte de
>temps. L'échec complet de SPIP-Agora en est la meilleure preuve.
>
>
>
>En résumé, Drupal est un bon logiciel mais son coté "couteau-suisse" est passé
>de mode. Les wikis sont des outils plus simples, plus conviviaux et plus
>ouverts. Dans la pluspart des cas, ils remplacent avantageusement les gros
>CMS comme Drupal
>
>
>bonne journée :)
>
>--
>damien clochard
>http://dalibo.org | http://dalibo.com
>
>--
>Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-fr-generale


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

Re: [GENERAL] PL/R download

On 27 May 2008, at 13:47, Cindy Makarowsky wrote:

> Is the PL/R download still available? The link is dead from the
> Postgres site and also at www.joeconway.com.

Is there another
> location available to download the installer?
>

have you tried here:

http://www.joeconway.com/plr/

all the download links there still work for me ...

adam

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

Re: [GENERAL] XML Support related questions

Thanks Peter for your responses. I will try constraint for # 1 but I
think it
probably will still make sense to include that as part of XML column
definition.
I assume the default xml data type is of CONTENT type.

For #4 I was looking to be able to index some or all of the tags in the
xml document. Most of our applications query very few tags in a Xml
document
and a smaller index on few tags will help with query performance.

Any guess on timeframe for #2, #3 and #4?

Thanks,
Brijesh


-----Original Message-----
From: Peter Eisentraut [mailto:peter_e@gmx.net]
Sent: Saturday, May 24, 2008 4:32 AM
To: pgsql-general@postgresql.org
Cc: Brijesh Shrivastav
Subject: Re: [GENERAL] XML Support related questions

Am Donnerstag, 22. Mai 2008 schrieb Brijesh Shrivastav:
> 1) Can xml column be constrained to be DOCUMENT or CONTENT type?

Using a check constraint that does IS [NOT] DOCUMENT on the value.

> 2) Is there plan in near future to support XML schema validation
> i.e to ensure inserted xml document conforms to a preregistered set of
> XML schemas.

Plans yes, but I don't think anyone is working on it at the moment.

> 3) Support for XQuery - I know it is asking for too much but when
> do you see it happening in the future.

See #2.

> 4) Support for xml indexes - Is it something that is being worked
> upon for next release?

See #3. ;-) Of course this question is a bit underspecified, because
indexes
depend on some operators, and XML does not have any operators at the
moment,
so what do you want to index?


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

Re: [GENERAL] New MS patent: sounds like PG db rules

Here is the US patent offices website to
i copy and pasted the wrong link. opps
http://www.uspto.gov/web/offices/dcom/bpai/index.html

Justin wrote:


Andrew Sullivan wrote:
On Tue, May 27, 2008 at 02:18:31PM +0100, Dave Page wrote:    
I don't think it's a major issue. Even if MS do think we infringe on the patent it would be laughable for them to try to do anything about it given that our rules implementation has provably existed in a leading FOSS project for a decade or more.     
 Unfortuately, it would only be laughable until they sued someone (or, more likely, threatened to do) who was selling PosrgreSQL.  The problem in such cases is that proving your obvious prior art is an expensive undertaking.  The likely path for a targeted "infringer" is just to give up and either pay something to MS or else use some other engine that doesn't "infringe".  This is exactly the sort of nonsense that causes people to think the US PTO is just completely broken.   A   
Yes completely agree.   The prospect of fighting is daunting, desire to run for the hills more desirable

We could start the objecting process instead waiting for MS to come after us.  Anybody want to relive the Blackberry nightmare?
http://www.ipo.gov.uk/patent/p-other/p-object.htm

What Tome Lane brought up could be a very big concern, but if the developers of said code new nothing about the patent and never used MS products then its an independent invention.  But proving that is very costly

Re: [GENERAL] PL/R download

Cindy Makarowsky wrote:
> Is the PL/R download still available? The link is dead from the
> Postgres site and also at www.joeconway.com <http://www.joeconway.com>.
> Is there another location available to download the installer?

Sorry, my bad. Fixed

Joe

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

[PATCHES] Doc patch: type modifiers

diff --git a/doc/src/sgml/ref/create_type.sgml b/doc/src/sgml/ref/create_type.sgml
index 641c13e..d7d1a0b 100644
--- a/doc/src/sgml/ref/create_type.sgml
+++ b/doc/src/sgml/ref/create_type.sgml
@@ -433,7 +433,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
<term><replaceable class="parameter">type_modifier_input_function</replaceable></term>
<listitem>
<para>
- The name of a function that converts numeric modifier(s) for the type
+ The name of a function that converts textual modifier(s) for the type
into internal form.
</para>
</listitem>
From
http://developer.postgresql.org/pgdocs/postgres/sql-createtype.html :

type_modifier_input_function

The name of a function that converts numeric modifier(s) for the
type into internal form.

type_modifier_output_function

The name of a function that converts the internal form of the
type's modifier(s) to external textual form.

But the paragraph above says:

"...take one or more simple constants or identifiers as modifiers..."

So in the description of the input function, "numeric" is wrong, and
should be something like "textual" (for the sake of symmetry).

Patch attached.

Regards,
Jeff Davis

[pgsql-es-ayuda] Error fatal en base de datos

Hola a todos,

Tengo instalada una base de datos postgres 8.1 en un servidor con debian.
Desde hace una semana más o menos al intentar arrancar las aplicaciones que
conectan con la base de datos me aparece este error en el log del sistema:

2008-05-26 12:19:40 CEST PANIC: no se pudo escribir archivo de registro 3,
segmento 87 en la posición 12623872, largo 16384: No queda espacio en el
dispositivo
2008-05-26 12:19:40 CEST SENTENCIA: update configuracio set
user_home='/root';
2008-05-26 12:19:40 CEST LOG: proceso de servidor (PID 10896) fue terminado
por una señal 6
2008-05-26 12:19:40 CEST LOG: terminando todos los otros procesos de
servidor activos
2008-05-26 12:19:40 CEST LOG: todos los procesos fueron terminados;
reinicializando
2008-05-26 12:19:40 CEST LOG: el sistema de bases de datos fue interrumpido
en 2008-05-26 12:18:52 CEST
2008-05-26 12:19:40 CEST LOG: el registro de checkpoint está en 3/57C0BAB4
2008-05-26 12:19:40 CEST LOG: registro de redo en 3/57C0BAB4; registro de
undo en 0/0; apagado TRUE
2008-05-26 12:19:40 CEST LOG: siguiente ID de transacción: 51807360;
siguiente OID: 17712
2008-05-26 12:19:40 CEST LOG: siguiente MultiXactId: 29; siguiente
MultiXactOffset: 57
2008-05-26 12:19:40 CEST LOG: el sistema de bases de datos no fue apagado
apropiadamente; se está efectuando la recuperación automática
2008-05-26 12:19:47 CEST LOG: no se pudo leer el archivo de registro 3,
segmento 87, posición 12632064: Error de entrada/salida
2008-05-26 12:19:47 CEST LOG: no se requiere redo
2008-05-26 12:19:47 CEST LOG: el sistema de bases de datos está listo
2008-05-26 12:19:47 CEST LOG: el límite para el reciclaje de ID de
transacciones es 2147484146, limitado por base de datos «postgres»


El disco físico no está lleno porque hay más de un 75% de espacio libre y
entiendo que no es un problema de llenado de los tablespaces de la base de
datos no? Además todo intento de conectar a la base de datos a través de
algún cliente de administración termina con error de I/O.

Espero que me podáis echar una mano para aclararme un poco.

Muchas gracias.

--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [GENERAL] New MS patent: sounds like PG db rules



Andrew Sullivan wrote:
On Tue, May 27, 2008 at 02:18:31PM +0100, Dave Page wrote:    
I don't think it's a major issue. Even if MS do think we infringe on the patent it would be laughable for them to try to do anything about it given that our rules implementation has provably existed in a leading FOSS project for a decade or more.     
 Unfortuately, it would only be laughable until they sued someone (or, more likely, threatened to do) who was selling PosrgreSQL.  The problem in such cases is that proving your obvious prior art is an expensive undertaking.  The likely path for a targeted "infringer" is just to give up and either pay something to MS or else use some other engine that doesn't "infringe".  This is exactly the sort of nonsense that causes people to think the US PTO is just completely broken.   A   
Yes completely agree.   The prospect of fighting is daunting, desire to run for the hills more desirable

We could start the objecting process instead waiting for MS to come after us.  Anybody want to relive the Blackberry nightmare?
http://www.ipo.gov.uk/patent/p-other/p-object.htm

What Tome Lane brought up could be a very big concern, but if the developers of said code new nothing about the patent and never used MS products then its an independent invention.  But proving that is very costly

[BUGS] BUG #4203: perform dblink() in begin/exception returns wrong SQLSTATE code

The following bug has been logged online:

Bug reference: 4203
Logged by: Henry Combrinck
Email address: henry@zen.co.za
PostgreSQL version: 8.2.6 and 8.3.1
Operating system: Linux
Description: perform dblink() in begin/exception returns wrong
SQLSTATE code
Details:

Apologies if this is the wrong forum to report this (perhaps it needs to go
to the dblink() maintainer?)

In a function on a machine using 8.2.6, the following returns a strange
SQLSTATE code:

begin
perform dblink ('host=other_machine ...',
'insert into table...');
exception when others then
raise notice 'SQLSTATE: %', SQLSTATE;
end;

The code returned is always 42601 (syntax_error) irrespective of the actual
error (eg, unique_violation).

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

Re: [GENERAL] New MS patent: sounds like PG db rules

On Tue, May 27, 2008 at 10:38:42AM -0400, Justin wrote:
> Postgresql is
> luck in the fact US patent laws are still based on the idea first to
> invent not first to patent which several countries have gone to.

Which has nothing to do with the matter at hand. It just means that MS
can claim to have invented it up to a year prior to filing which would
be problematic if the SE-Postgres patch is affected.

The rules system is way older and so not at risk either way.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org>

http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Re: [PERFORM] [GENERAL] select query takes 13 seconds to run with index

On Tue, May 27, 2008 at 07:46:05AM -0700, mark wrote:
> and then it became super fast!! thanks a lot!!!
> my question:
> -> is 500 too high? what all does this affect?

i usually dont go over 100. it affects number of elements in statistics
for fields. you can see the stats in:
select * from pg_stats;

> -> now increasing this number does it affect only when i am running
> analyze commands, or will it slow down inserts and other operations?
> EXPLAIN ANALYZE select * from pokes where uid = 578439028 order by id
> desc limit 6;

it (theoretically) can slow down selects to to the fact that it now has
to load more data to be able to plan (i.e. it loads the statistics, and
since there are more values - the statistics are larger).

generally - in most cases this shouldn't be an issue.

additionally - i think that the 2-column index would work in this
particular case even better.

regards,

depesz

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

Re: [pgsql-es-ayuda] almacenar en bd o no?

2008/5/27 Mario Wojcik <mariowojcik@yahoo.com.ar>:
> Crispin T. escribió:
>>
>> hola tengo un problema resulta que tengo un sistema en java con bd
>> postgres 8.2 y todo me va de maravilla pero empieza a preocuparme un asunto,
>> resulta que por performance y por no cargar demasiado la bd no almacene las
>> fotos de unos inmuebles en al bd pero me resulta complicado al momento de
>> hacer backups ya que las imagenes las agarro como archivos y pues copiar
>> varios archivos y restaurar varios archivos ademas de los datos de la bd se
>> me hace mucho trabajo y mucho tiempo pero no me anime a almacenarlos en un
>> tipo oid porque por cada inmueble se manejan alrededor de 30 fotos png de
>> 600x500 aproximadamente, ademas que antes el sistema hera monolitoco (corria
>> en una unica pc) pero ahora el negocio crecio y se necesita que corra en una
>> lan y bueno nose como hacer que una aplicación java cargue archivos que
>> estan en otra pc (no veo seguro compartir la carpeta de los archivos) y me
>> estoy animando a guardar las imagenes en la bd
>>
>> dados los casos ¿que harian ustedes en este caso?
>> en el caso de sugerirme que guarde las imagenes en la bd ¿hay forma de
>> sacar backup's de solo algunas tablas?
>> en caso de no guardar en la bd las imagenes ¿que solucion me sugieren para
>> cargar imagenes desde otra pc(sin compartir la carpeta)?
>>
>> gracias.
>>
>> Crispin.
>
> Hola!
> Para asegurarme de mantener la integridad, yo la metería en una tabla
> que tenga solo un campo ID del tipo serial, un campo ID_Inmueble para
> relacionarla y el campo imagen.
> Entonces, la consulta inicial se haría sobre los datos principales
> (dirección, precio, zona, etc) y, si queremos, hacemos la consulta (mas
> lenta) de las imágenes.
> Opcionalmente, en la tabla principal pondría una imagen muy pequeña como
> referencia visual pero las demás 30 fotos sobre la otra tabla...
> Creo que es un esquema bastante eficiente (en teoría) y evitas las
> referencias que van a ser un dolor de cabeza no solo para las copias,
> sino para cualquier mantenimiento que quieras dar a tu sistema...
>
> --
> ========================
> WOJCIK, MARIO A.
> ========================
> Leandro N Alem -Misiones
> ------------------------
> A R G E N T I N A
> ------------------------
> mariowojcik@yahoo.com.ar
>
>
> --
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
>

http://archives.postgresql.org/pgsql-es-ayuda
>

Concuerdo con esto que se propone de echo lo que haciamos en mi
antigüo trabajo era guardar la ruta de la imagen y el nombre la imagen
(que era escaneada ) se trataba para indexar el nombre del archivo
como <fecha dd-mm-aaaa-mm:ss:ns) lo que hacia que cada imagen se
guardara asociada a una transaccion de manera unica despues , como
estas trabajando en Java supongo que tu sistema sera web tu cargas
desde la BD solo los nombres de las imagenes y las despliegas no se si
me hago entender??? ...
El tema era que teniamos una base relativamente "relajada" que
controlaba muchas transacciones criticas, porque si paraba el proceso
armabamos unas filas de camiones que ni te digo... sin mayores
sobresaltos...
El tema que tienes que tener en cuenta es que despues el Backup de la
carpeta con imagenes se vuelve todo un problema pero puedes buscar
maneras de indexar las imagenes y acotar las busquedas por ejemplo por
años...
Slds.
J.


--
----------------------
Slds.
jchavez
linux User #397972 on http://counter.li.org/
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [GENERAL] New MS patent: sounds like PG db rules

On Tue, May 27, 2008 at 02:18:31PM +0100, Dave Page wrote:

> I don't think it's a major issue. Even if MS do think we infringe on
> the patent it would be laughable for them to try to do anything about
> it given that our rules implementation has provably existed in a
> leading FOSS project for a decade or more.

Unfortuately, it would only be laughable until they sued someone (or,
more likely, threatened to do) who was selling PosrgreSQL.

The problem in such cases is that proving your obvious prior art is an
expensive undertaking. The likely path for a targeted "infringer" is
just to give up and either pay something to MS or else use some other
engine that doesn't "infringe".

This is exactly the sort of nonsense that causes people to think the
US PTO is just completely broken.

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

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

Re: [HACKERS] WITH RECURSIVE patches V0.1 TODO items

* Tatsuo Ishii <ishii@postgresql.org> [080527 10:40]:

> In my understanding, yes.

If you want to push back to the same location, yes, you'll all need
accounts at the same location giving you permission to push there.

Technically, you could all "share" an account there too, but the
drawbacks to lack of accountability usually mean separate accounts is a
better solution.

> And I think even if we would have accounts on the community git
> server, we cannot push (commit) to the repository. Probably all we can
> do is, get the diff between someone's pushed data and the origin.

No, it's easy to set it up so you can directly push to a shared
repository, or each push to your individual repositories and
"pull/merge" others changes into your own. Or any combination of the
above.

a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/

work like a slave.

Re: [HACKERS] WITH RECURSIVE patches V0.1 TODO items

On Tue, May 27, 2008 at 12:11:54PM +0200, Michael Meskes wrote:
> On Mon, May 26, 2008 at 07:23:24PM -0700, David Fetter wrote:
> > Right for this case. Is there some way to estimate this short of
> > a full-on materialized views implementation? I'm guessing we'd
> > need to be able to cache the transitive closure of such searches.
>
> You'd like to cache the whole closure? Or just some stats about it?

This is getting way past my knowledge. What kind of stats could be
kept?

Since WITH RECURSIVE doesn't require that any DDL be issued in
advance, we'd need some kind of infrastructure--possibly we have it
today--which could collect those statistics on DML calls.

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-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PERFORM] [GENERAL] select query takes 13 seconds to run with index

On Tue, May 27, 2008 at 1:22 AM, hubert depesz lubaczewski
<depesz@depesz.com> wrote:
> On Mon, May 26, 2008 at 04:32:50PM -0700, mark wrote:
>> >> EXPLAIN ANALYZE select * from pokes where uid = 578439028 order by id
>> >> DESC limit 6;
>> > The estimate is way off, when was the last time Vaccum was on the table?
>> about a week ago i ran this VACUUM VERBOSE ANALYZE;
>> this table is never updated or deleted, rows are just inserted...
>
> 1. boost default_statistics_target
> 2. run analyze more often - daily job for example
> 3. create index q on pokes (uid, id); should help

OK I did this

ALTER TABLE pokes ALTER uid set statistics 500;
ALTER TABLE

ANALYZE pokes;
ANALYZE

and then it became super fast!! thanks a lot!!!
my question:
-> is 500 too high? what all does this affect?
-> now increasing this number does it affect only when i am running
analyze commands, or will it slow down inserts and other operations?
EXPLAIN ANALYZE select * from pokes where uid = 578439028 order by id
desc limit 6;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=467.80..467.81 rows=6 width=134) (actual
time=0.016..0.016 rows=0 loops=1)
-> Sort (cost=467.80..468.09 rows=117 width=134) (actual
time=0.016..0.016 rows=0 loops=1)
Sort Key: id
Sort Method: quicksort Memory: 25kB
-> Index Scan using idx_pokes_uid on pokes
(cost=0.00..465.70 rows=117 width=134) (actual time=0.011..0.011
rows=0 loops=1)
Index Cond: (uid = 578439028)
Total runtime: 0.037 ms

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

Re: [GENERAL] New MS patent: sounds like PG db rules

"Dave Page" <dpage@pgadmin.org> writes:
> On Tue, May 27, 2008 at 2:06 PM, Justin Clift <justin@salasaga.org> wrote:
>> I'm trying to point out that - PG is a database system - and MS may have
>> just been granted a patent for a fundamental part of it.

> I don't think it's a major issue. Even if MS do think we infringe on
> the patent it would be laughable for them to try to do anything about
> it given that our rules implementation has provably existed in a
> leading FOSS project for a decade or more.

Right --- if in fact PG's rules infringe, then the patent is invalid
because we are prior art.

After scanning the claims, though, most of this is about access-rights
enforcement; which is something that rules *could* be used for but it's
not their sole or main purpose. What it seems a whole lot closer to
is Veil or SEPostgres. I think those projects have reason to be very
afraid.

In fact, I suspect that the originally submitted version of SEPostgres
does infringe the patent, and that code is not old enough to be prior
art. The part of the patch that looks like this patent to me is the
part that enforces row-level access checks by adding constraints to a
querytree's WHERE clause.

I had already suggested to KaiGai-san that he get rid of that in favor
of low-level checks in the executor, but the need to avoid an M$ patent
makes it even more important ...

regards, tom lane

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

Re: [HACKERS] WITH RECURSIVE patches V0.1 TODO items

* Tatsuo Ishii <ishii@postgresql.org> [080527 10:12]:

> I don't stick to CVS at all. If contributors are comfortable, let's go
> with GIT.
>
> BTW, does this setting requrie a local GIT server be installed? If so,
> that might be a problem for me since I don't have resource for that.

GIT is a completely distributed VCS/SCM. This means that every single
local clone of a repository is a completely self-sufficent repository.
So you never need to have a "local server" to do anything in GIT.

When people think of "git servers", they are generally thinking of 2
things:
1) Gitweb - the "web interface" to a git repo
2) "public repositories" via git:// git protocol

Neither of these are necessary to use git "locally", but are means for
exchaning/sharing the current state of a repository.

The git protocol is a normal send/receive transfer mechanism, of the
same sort as CVS. Most people using git use it over SSH when pushing
their changes to public places. The git-daemon server serves the
"git://" protocol over any port (usually 9418) and is a way to give
anonymous access to a git repo (usually read-only, but can be
read-write) without needing to give SSH access, like cvs pserver.

But the short of it is, git.postgresql.org runs both gitweb and
git-daemon for you, so if you want to use git, all you need is a local
git package, and SSH access to git.postgresql.org, which can do all the
public serving/sharing for you.

I guess I should have had a GIT talk/intro/anything over lunch or
something last week at PGCon. I hadn't thought of it then... Bummer...

a.

--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/

work like a slave.

Re: [GENERAL] New MS patent: sounds like PG db rules



Dave Page wrote:
On Tue, May 27, 2008 at 2:59 PM, Justin <justin@emproshunts.com> wrote:   
Dave Page wrote:  Having been involved in lawsuits, i wish it was a laughing manner.  Thinking a patent is unenforceable is dangerous thinking.  MS could target the leaders of the community along with the corporate sponsors.     
 Well as one of those people, working for one of those companies, I'm not going to lose any sleep over it. The fact is that Microsoft do have vaguely sane lawyers and I have little doubt they would do some elementary research before trying to claim that  our 10 year old (probably much older in fact, as I believe there was a rules system in the code inherited from Berkley) feature infringes their 2 year old patent. Whilst it is true it could get expensive if they did try, I don't believe they will as they would ultimately end up with egg on their faces and would likely cost them real money and be the cause of significant bad press.    
I'm not losing any sleep over it either and you may be very right.  But don't bet on the side intelligent/logical thinking to coming out of a lawyer who's on retainer to a big corporation like MS.  Postgresql is luck in the fact US patent laws are still based on the idea first to invent not first to patent which several countries have gone to.


Re: [HACKERS] WITH RECURSIVE patches V0.1 TODO items

> > BTW, does this setting requrie a local GIT server be installed? If so,
> > that might be a problem for me since I don't have resource for that.
>
> Selena was saying that there was a community git server we could use for this.
> I didn't catch who to speak to (Josh?) to set up an account.
>
> And would we all need accounts if we want to push back changes?

In my understanding, yes.

And I think even if we would have accounts on the community git
server, we cannot push (commit) to the repository. Probably all we can
do is, get the diff between someone's pushed data and the origin.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

--
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] WITH RECURSIVE patches V0.1 TODO items

On Tue, May 27, 2008 at 10:30:44AM -0400, Gregory Stark wrote:
> "Tatsuo Ishii" <ishii@postgresql.org> writes:
>
> > If contributors are comfortable, let's go with GIT.
> >
> > BTW, does this setting requrie a local GIT server be installed? If
> > so, that might be a problem for me since I don't have resource for
> > that.
>
> Selena was saying that there was a community git server we could use
> for this. I didn't catch who to speak to (Josh?) to set up an
> account.

Peter Eisentraut, as I recall.

> And would we all need accounts if we want to push back changes?

Yep.

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-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-es-ayuda] almacenar en bd o no?

Crispin T. escribió:
> hola tengo un problema resulta que tengo un sistema en java con bd
> postgres 8.2 y todo me va de maravilla pero empieza a preocuparme un
> asunto, resulta que por performance y por no cargar demasiado la bd no
> almacene las fotos de unos inmuebles en al bd pero me resulta
> complicado al momento de hacer backups ya que las imagenes las agarro
> como archivos y pues copiar varios archivos y restaurar varios
> archivos ademas de los datos de la bd se me hace mucho trabajo y mucho
> tiempo pero no me anime a almacenarlos en un tipo oid porque por cada
> inmueble se manejan alrededor de 30 fotos png de 600x500
> aproximadamente, ademas que antes el sistema hera monolitoco (corria
> en una unica pc) pero ahora el negocio crecio y se necesita que corra
> en una lan y bueno nose como hacer que una aplicación java cargue
> archivos que estan en otra pc (no veo seguro compartir la carpeta de
> los archivos) y me estoy animando a guardar las imagenes en la bd
>
> dados los casos ¿que harian ustedes en este caso?
> en el caso de sugerirme que guarde las imagenes en la bd ¿hay forma de
> sacar backup's de solo algunas tablas?
> en caso de no guardar en la bd las imagenes ¿que solucion me sugieren
> para cargar imagenes desde otra pc(sin compartir la carpeta)?
>
> gracias.
>
> Crispin.
Hola!
Para asegurarme de mantener la integridad, yo la metería en una tabla
que tenga solo un campo ID del tipo serial, un campo ID_Inmueble para
relacionarla y el campo imagen.
Entonces, la consulta inicial se haría sobre los datos principales
(dirección, precio, zona, etc) y, si queremos, hacemos la consulta (mas
lenta) de las imágenes.
Opcionalmente, en la tabla principal pondría una imagen muy pequeña como
referencia visual pero las demás 30 fotos sobre la otra tabla...
Creo que es un esquema bastante eficiente (en teoría) y evitas las
referencias que van a ser un dolor de cabeza no solo para las copias,
sino para cualquier mantenimiento que quieras dar a tu sistema...

--
========================
WOJCIK, MARIO A.
========================
Leandro N Alem -Misiones
------------------------
A R G E N T I N A
------------------------
mariowojcik@yahoo.com.ar


--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

Re: [HACKERS] WITH RECURSIVE patches V0.1 TODO items

"Tatsuo Ishii" <ishii@postgresql.org> writes:

> If contributors are comfortable, let's go with GIT.
>
> BTW, does this setting requrie a local GIT server be installed? If so,
> that might be a problem for me since I don't have resource for that.

Selena was saying that there was a community git server we could use for this.
I didn't catch who to speak to (Josh?) to set up an account.

And would we all need accounts if we want to push back changes?

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's PostGIS support!

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

[SQL] Enumerated (enum) types

Enumerated (enum) types are data types that are comprised of a static, predefined set of values with a specific order. They are equivalent to the enum types in a number of programming languages. An example of an enum type might be the days of the week, or a set of status values for a piece of data.

Declaration of Enumerated Types

Enum types are created using the CREATE TYPE command, for example:

CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy');

Once created, the enum type can be used in table and function definitions much like any other type:

Example. Basic Enum Usage

CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy');
CREATE TABLE person (
name text,
current_mood mood
);
INSERT INTO person VALUES ('Moe', 'happy');
SELECT * FROM person WHERE current_mood = 'happy';
name | current_mood
------+--------------
Moe | happy
(1 row)

Ordering

The ordering of the values in an enum type is the order in which the values were listed when the type was declared. All standard comparison operators and related aggregate functions are supported for enums. For example:

Example. Enum Ordering

INSERT INTO person VALUES ('Larry', 'sad');
INSERT INTO person VALUES ('Curly', 'ok');
SELECT * FROM person WHERE current_mood > 'sad';
name | current_mood
-------+--------------
Moe | happy
Curly | ok
(2 rows)
SELECT * FROM person WHERE current_mood > 'sad' ORDER BY current_mood;
name | current_mood
-------+--------------
Curly | ok
Moe | happy
(2 rows)
SELECT name FROM person
WHERE current_mood = (SELECT MIN(current_mood) FROM person);
name
-------
Larry
(1 row)

Type Safety

Enumerated types are completely separate data types and may not be compared with each other.

Example. Lack of Casting

CREATE TYPE happiness AS ENUM ('happy', 'very happy', 'ecstatic');
CREATE TABLE holidays (
num_weeks int,
happiness happiness
);
INSERT INTO holidays(num_weeks,happiness) VALUES (4, 'happy');
INSERT INTO holidays(num_weeks,happiness) VALUES (6, 'very happy');
INSERT INTO holidays(num_weeks,happiness) VALUES (8, 'ecstatic');
INSERT INTO holidays(num_weeks,happiness) VALUES (2, 'sad');
ERROR: invalid input value for enum happiness: "sad"
SELECT person.name, holidays.num_weeks FROM person, holidays
WHERE person.current_mood = holidays.happiness;
ERROR: operator does not exist: mood = happiness

If you really need to do something like that, you can either write a custom operator or add explicit casts to your query:

Example. Comparing Different Enums by Casting to Text

SELECT person.name, holidays.num_weeks FROM person, holidays
WHERE person.current_mood::text = holidays.happiness::text;
name | num_weeks
------+-----------
Moe | 4
(1 row)

Implementation Details

An enum value occupies four bytes on disk. The length of an enum value's textual label is limited by the NAMEDATALEN setting compiled into PostgreSQL; in standard builds this means at most 63 bytes.

Enum labels are case sensitive, so 'happy' is not the same as 'HAPPY'. Spaces in the labels are significant, too.

An Alternative Way To Do The Same

Instead of using an enum type we can set up a CHECK CONSTRAINT - this tells postgresql to make sure that the value we are entering is valid.

CREATE TABLE person (
personid int not null primary key,
favourite_colour varchar(255) NOT NULL,
CHECK (favourite_colour IN ('red', 'blue', 'yellow', 'purple'))
);
INSERT INTO person(personid, favourite_colour) VALUES (1, 'red');
INSERT 0 1

Now for something not in the list:

INSERT INTO person(personid, favourite_colour) VALUES (2, 'green');
ERROR: new row for relation "person" violates check constraint "person_favourite_colour_check"

--
Michael Lourant
"All you need is love"

Re: [GENERAL] Annoying messages when copy sql code to psql terminal

"A B" <gentosaker@gmail.com> writes:
> Whenever I use copy-paste to run code in a terminal window that is
> running psql, and the code contains a row like

> IF FOUND THEN

> then I get the words

> ABORT CHECKPOINT COMMIT DECLARE EXECUTE
> ...

Either avoid copying/pasting tabs, or turn off readline
(-n option to psql, I think, but check the manual).

There's probably a way to turn off tab-completion without
disabling readline altogether, but I don't know how offhand.

regards, tom lane

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

[ADMIN] Postgres will not shutdown?

Hello,

I've had a number of problems with Postgres in passed few days.
First ,I had an issue with a corrupt index. One solution required
that I stop and start postgres so it would read the postgresql.conf
file. It looked like it was stopping but it wasn't. I finally had
to kill the processes. The problem was that postgres didn't thing
the pg_ctl was running. Then I realized I had not set the parameter
that I needed to set quite high enough so I had to stop and restart
it again. It didn't stop again but this time I got the following
message:

# /etc/init.d/cswpostgres stop
Stopping PostgreSQL database...
waiting for server to shut
down...............................................................
failed
pg_ctl: server does not shut down

Can anyone help unravel this?

Thanks in advance,

Carol

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

Re: [BUGS] BUG #4196: Backend crash possible with psql

"Daniel Mihowski" <dmigowski@ikoffice.de> writes:
> Bug reference: 4196
> Logged by: Daniel Mihowski
> Email address: dmigowski@ikoffice.de
> PostgreSQL version: 8.3.1
> Operating system: Windows XP
> Description: Backend crash possible with psql
> Details:

> Hello, dear developers. When accessing the local postgresql server with
> PGAdmin, it closes abnormally. This is my psql window:

This is now believed fixed, and will be in 8.3.2:
http://archives.postgresql.org/pgsql-committers/2008-05/msg00349.php

Thanks for your help in isolating the cause.

regards, tom lane

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

Re: [PATCHES] LOCK_DEBUG documentation

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


Tom Lane replied:
>> Documentation patch by Kevin L. McBride explaining LOCK_DEBUG options
>> in detail.

> Should this stuff really go into the SGML documentation, when these
> options will certainly never be enabled anywhere except in developers'
> private builds? A few lines of comments in pg_config_manual.h seems
> a more appropriate solution.

Call me a traditionalist, but I like all the documentation in one place,
even if some of it it seldom used. For the record, these options have
been enabled by myself and others in production systems for debugging
purposes, and the lack of detail in that section while doing so led to
the patch. The docs also has the advantage of being more available,
searchable, and found via the web.

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

iEYEAREDAAYFAkg8F04ACgkQvJuQZxSWSsjNiQCffXM6m8N6DGW9fP3LmVvIGMDo
Y30AoJ0fD2G0n1j5g1HdOukFWppd8jgu
=6tFr
-----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

Re: [GENERAL] New MS patent: sounds like PG db rules

On Tue, May 27, 2008 at 2:59 PM, Justin <justin@emproshunts.com> wrote:
> Dave Page wrote:
>
> Having been involved in lawsuits, i wish it was a laughing manner. Thinking
> a patent is unenforceable is dangerous thinking. MS could target the
> leaders of the community along with the corporate sponsors.

Well as one of those people, working for one of those companies, I'm
not going to lose any sleep over it. The fact is that Microsoft do
have vaguely sane lawyers and I have little doubt they would do some
elementary research before trying to claim that our 10 year old
(probably much older in fact, as I believe there was a rules system in
the code inherited from Berkley) feature infringes their 2 year old
patent. Whilst it is true it could get expensive if they did try, I
don't believe they will as they would ultimately end up with egg on
their faces and would likely cost them real money and be the cause of
significant bad press.


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Re: [pgeu-general] Public announcement

On Tue, May 27, 2008 at 09:49:58AM +0200, damien clochard wrote:
> On april 26th, 2008 the French Official Journal published the public
> announcement of PostgreSQL Europe. This was the last step of the
> legal/adminstrative work to create PostgreSQL Europe association.
>
> I('m happy the announce that all legal stuffs are done. The PostgreSQL Europe
> association is now fully and officialy founded.

Yay!

> You can check the public announcement on our brand new wiki :
>
> http://wiki.postgresql.eu/wiki/Image:Postgresql_europe_jo.pdf

Brrr, pdf :)

> Next step is now to search for a bank and open an account for the association.
> If any of you has some experience on managing a bank account for an European
> non-profit , please share with us :-)

I don't have much experience regarding that, it just seems that it would
be wise to have the account in the same country as that of incorporation
(so that would be France, no?).

Of course, the bank must be using PostgreSQL :)

A small tip: make sure that the treasurer is not the only person who can
access the account, that might lead to some inconvenient situations.

Best,

Koen

--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, hosting, embedded systems, unix, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

Re: [HACKERS] ERRORDATA_STACK_SIZE panic crashes on Windows

Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> Fortunately there is a way to tell gettext what to do, and accordingly
>> I propose the attached patch. I am not in a position to test it
>> however. Would somebody replicate the failure and confirm this
>> fixes it?

> After some work, I've managed to reproduce it in my test environment for
> Swedish, and I can confirm that the patch fixes the issue.

Thanks.

> Just for kicks, I've applied this patch so you, so you get to be on the
> receiving side of that ;-)

No objection here.

I noticed that you applied the patch to 8.2 as well. It should be
harmless enough, but we weren't having the problem in 8.2 were we?
Or am I just confused?

regards, tom lane

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

Re: [HACKERS] WITH RECURSIVE patches V0.1 TODO items

> "Aidan Van Dyk" <aidan@highrise.ca> writes:
>
> > Something like this is easily done in GIT as well:
> > git fetch ## Fetch any new commits done in the origin to the local repo
> > git merge origin/master ## or any other branch you want..
> > git push ## publish your work for others to fetch
>
>
> I would very much like to start using GIT to do this. The main difference is
> that when a contributor wants to merge back the changes from upstream GIT
> knows which changes upstream correspond to the commits the contributor made.
> So it can avoid a lot of conflicts when the upstream version has subsequent
> changes to the same areas.
>
> The end result is also a lot cleaner. Instead of a lot of commit messages that
> just say "applying patch from Foo" all the original separate commits can be
> preserved.

I don't stick to CVS at all. If contributors are comfortable, let's go
with GIT.

BTW, does this setting requrie a local GIT server be installed? If so,
that might be a problem for me since I don't have resource for that.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

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

[GENERAL] PL/R download

Is the PL/R download still available?  The link is dead from the Postgres site and also at www.joeconway.com.  Is there another location available to download the installer?
 
Thanks,
 
Cindy

Re: [pgsql-es-ayuda] Error fatal en base de datos

El mar, 27-05-2008 a las 17:19 +0200, Javier Felipe Villa escribió:
> Hola a todos,

Hola,

> Tengo instalada una base de datos postgres 8.1 en un servidor con debian.
> Desde hace una semana más o menos al intentar arrancar las aplicaciones que
> conectan con la base de datos me aparece este error en el log del sistema:

Ejecuta

df -h

y envia la salida a la lista.

Saludos,

-- Mauro

> 2008-05-26 12:19:40 CEST PANIC: no se pudo escribir archivo de registro 3,
> segmento 87 en la posición 12623872, largo 16384: No queda espacio en el
> dispositivo
> 2008-05-26 12:19:40 CEST SENTENCIA: update configuracio set
> user_home='/root';
> 2008-05-26 12:19:40 CEST LOG: proceso de servidor (PID 10896) fue terminado
> por una señal 6
> 2008-05-26 12:19:40 CEST LOG: terminando todos los otros procesos de
> servidor activos
> 2008-05-26 12:19:40 CEST LOG: todos los procesos fueron terminados;
> reinicializando
> 2008-05-26 12:19:40 CEST LOG: el sistema de bases de datos fue interrumpido
> en 2008-05-26 12:18:52 CEST
> 2008-05-26 12:19:40 CEST LOG: el registro de checkpoint está en 3/57C0BAB4
> 2008-05-26 12:19:40 CEST LOG: registro de redo en 3/57C0BAB4; registro de
> undo en 0/0; apagado TRUE
> 2008-05-26 12:19:40 CEST LOG: siguiente ID de transacción: 51807360;
> siguiente OID: 17712
> 2008-05-26 12:19:40 CEST LOG: siguiente MultiXactId: 29; siguiente
> MultiXactOffset: 57
> 2008-05-26 12:19:40 CEST LOG: el sistema de bases de datos no fue apagado
> apropiadamente; se está efectuando la recuperación automática
> 2008-05-26 12:19:47 CEST LOG: no se pudo leer el archivo de registro 3,
> segmento 87, posición 12632064: Error de entrada/salida
> 2008-05-26 12:19:47 CEST LOG: no se requiere redo
> 2008-05-26 12:19:47 CEST LOG: el sistema de bases de datos está listo
> 2008-05-26 12:19:47 CEST LOG: el límite para el reciclaje de ID de
> transacciones es 2147484146, limitado por base de datos «postgres»
>
>
> El disco físico no está lleno porque hay más de un 75% de espacio libre y
> entiendo que no es un problema de llenado de los tablespaces de la base de
> datos no? Además todo intento de conectar a la base de datos a través de
> algún cliente de administración termina con error de I/O.
>
> Espero que me podáis echar una mano para aclararme un poco.
>
> Muchas gracias.
>
> --
> TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

--
TIP 8: explain analyze es tu amigo

[GENERAL] active queries

Hi!

Our company has a long last problem by using libpq in multi-threaded
programs. The libpq usually closes the programs without any error
message or rarely giving the 'Invalid frontend message type 87' error.
When asked you about this error message you gave the reply below. In the
reply there is only one thing which is not clear... What does an
'active' query mean? Or how can we detect active queries on a PGconn?
We have tried PQcancel() and PQreset() functions too, but they didn't
help solving the problem.
Our programs retrieve every result (PQgetResult() and PQclear()
functions) that is pending on the server before reusing a PGconn.

Thank you in advance
Attila Miklosi

P.S.: this is a copy of your reply to 'invalid frontend message type 87'
error message

>"Invalid frontend message" means the server got a message with an
>unexpected first byte, which usually means the server and libpq got
>out of sync about where the message boundaries are. It's been quite
>a long time since we've seen an actual bug of that sort, though.
>The cases that I've heard of recently involve multiple threads in an
>application trying to use the same PGconn without any interlocking.
>You can't have multiple queries active on a single connection, but
>libpq itself doesn't contain any locking to prevent multiple threads
>from trying to use the PGconn at once.
>
>If you're getting this with a single-threaded client, please submit
>a test case to pgsql-bugs.
>
> regards, tom lane

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