Saturday, August 16, 2008

[BUGS] BUG #4362: Casts from base types to composite types don't work.

The following bug has been logged online:

Bug reference: 4362
Logged by: Andrej Podzimek
Email address: andrej@podzimek.org
PostgreSQL version: 8.3
Operating system: Linux
Description: Casts from base types to composite types don't work.
Details:

CREATE TYPE pxgt_xid AS (xid bigint, xname text);

CREATE FUNCTION pxgt_xid(text) RETURNS pxgt_xid AS
$BODY$ select cast ( null as bigint ), $1; $BODY$
LANGUAGE 'sql' IMMUTABLE;

CREATE CAST (text AS pxgt_xid) WITH FUNCTION pxgt_xid(bigint) AS IMPLICIT;

select cast (text 'blabla' as pxgt_xid);
ERROR: malformed record literal: "blabla"
DETAIL: Missing left parenthesis.

When I create a similar cast for bigint->pxgt_xid, it seems to work. But in
fact an implicit cast works here, not the defined one... So as long as the
first field is a bigint, a default cast is used and the second field is just
set to null automatically. So implicit casts bigint->pxgt_xid and
(bigint)->pxgt_xid (with bigint in a simple record) work fine. But the cast
defined above is simply ignored.

AFAIK, the documentation does not mention that casts between base and
composite types are discouraged, prohibited or impossible.

Theoretically, it should be possible to create a function that accepts the
type pxgt_xid, which contains either a text or a numeric identifier. By
adding just one "is null" condition, one could have the code for both
identifier types in one function, without function overloading. That would
be great ... if the implicit cast above worked.

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

[GENERAL] selecting data from subquery in same order

hi
if i execute this statement:

select * from users where id in (2341548, 2325251, 2333130, 2015421,
2073536, 2252374, 2273219, 2350850, 2367318, 2032977, 2032849, )

the order of rows obtained is random.

is there anyway i can get the rows in the same order as the ids in
subquery? or is there a different statement i can use?
thanks!

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

Re: [COMMITTERS] pgsql: Make the pg_stat_activity view call a SRF

On Sat, Aug 16, 2008 at 12:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> regression=# select * from pg_show_all_settings();
> ERROR: a column definition list is required for functions returning "record"
>
> There's no longer any very good reason for built-in SRFs to not define
> their own output record type.
>

is there any one doing this? if not i want to give it a try... seems
easy enough, even for me :)

--
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157

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

[HACKERS] Limitations on trigger functions

I came across this bug tonight:

-- Function: pre_delete_main()

CREATE FUNCTION pre_delete_main()
RETURNS TRIGGER AS
$BODY$BEGIN
DROP TABLE bug_referring_table;
RETURN OLD;
END;$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;

-- Table: bug_referenced_table

CREATE TABLE bug_referenced_table
(
id integer NOT NULL,
CONSTRAINT bug_referenced_table_pkey PRIMARY KEY (id)
)
WITH (OIDS=FALSE);

-- Trigger: on_pre_delete_main on bug_referenced_table

CREATE TRIGGER on_pre_delete_main
BEFORE DELETE
ON bug_referenced_table
FOR EACH ROW
EXECUTE PROCEDURE pre_delete_main();

INSERT INTO bug_referenced_table VALUES (1);

-- Table: bug_referring_table

CREATE TABLE bug_referring_table
(
main_id integer NOT NULL,
CONSTRAINT bug_referring_table_main_id_fkey FOREIGN KEY (main_id)
REFERENCES bug_referenced_table (id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
)
WITH (OIDS=FALSE);

-- ERROR: cache lookup failed for constraint 19411

DELETE FROM bug_referenced_table WHERE id = 1;

It seems the trigger list is calculated once, and does not reflect
changes made by triggers in that list. Are there good reasons for
doing that? Should that behavior be changed?

The reason I wanted to do this was partitioning. By dropping the
partitions in a trigger, I can make deleting look the same to the
programmer with or without partitions. Because of this bug, the
programmer will first need to determine if the delete will cascade
normally (it does depending on which partition the record falls into)
or if he needs to drop partition tables first.

-Dan

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

Re: [NOVICE] using the system shadow passwd file for remote access

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

johnf wrote:
> On Thursday 14 August 2008 09:10:36 pm johnf wrote:
>> Hi,
>> If I set the auth method to 'ident' will postgres use the normal user table
>> to authorize the access? This is Linux.
>> --
>> John Fabiani
>
> Nobody knows? Should I ask in the general list?
>
I hope this helps: as a beginner there is not much I could say that
hasn't already been written; so, according to what I gather from the
documentation
(http://www.postgresql.org/docs/8.2/static/auth-methods.html#AUTH-IDENT)
the exact method used depends on the connection type (tcp/ip, socket)
and also on whether all PostgreSQL users are the same as the OS users.
I suggest you read the previous link, it is quite informative; you might
also want to read your pg_ident.conf file.

Regards,
Barbara Figueirido
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkinT40ACgkQGkaV37yLzcemQwCfW/rXehDXDZenq7g0WS+c7o1z
ZLMAn1gMVLnUHWKiIWVT70SH0HnpQf74
=IqmO
-----END PGP SIGNATURE-----

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

Re: [pgsql-es-ayuda] Postgres Vs. MySQL

Buenas tardes grupo sabes que estuve que desintalar mi postgres que tenia instalado  en windows para ayudar a una amiga y cuando lo volvi a instalar me presento algunos problemistas como esta "Al intentar reinstalar PostgreSQL aparece una ventana indicando lo siguiente:
Internal account lookup failure: No se ha efectuado ninguna asignación entre los nombres de cuenta y los identificadores de seguridad
".

y he buscado en foros y muchas veces en internet y nada espero que me puedan ayudar del resto tendre que formatear la maquina para volver a instalar

Re: [HACKERS] Plugin system like Firefox

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Le 12 août 08 à 18:41, Bruce Momjian a écrit :
>> Are you proposing that we should introduce our own packaging system
>> for
>> such add-on components? Like CP(g)AN (which has been proposed
>> before..)?
>
> Yes, pretty much. I imagine some kind of web interface or Java app
> (did
> I just say that?) that lists all plugins and when you choose one it
> downloads an object file appropriate for your operating system plus
> SQL
> scripts and somehow automatically installs them in the desired
> database.
>
> That is the kind of capability we need to really advance things. We
> would still allow source installs but for people wanting to try things
> out, I see no other alternative, and "try things out" == adoption.

What is wrong with my proposal here:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01098.php
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01116.php

I tried to address binary distribution, PostgreSQL stamped packages,
distributions packaging compliance (deb and rpm and etc), and ease of
use at user level (a package embeds .so file(s) with any SQL you need).

The proposal mention SQL level interface (create/drop/install package)
and command-line tools to fetch from internet, build with pgxs and
install the prepared package into the given database. The binary
distribution is left to people in charge in my proposal, they are
debian packagers, RPM ones like Devrim, or Win32 Installer team.

Please tell me how far from a workable proposal I am...

Regards,
- --
dim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkinRGoACgkQlBXRlnbh1bkTOgCfT7xerFH6i5Q2g35djcYoYGLI
7bMAn2/WqGyzVwf/8KAacpo9QCuYxv+G
=lZqK
-----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

[BUGS] BUG #4361: ODBC Driver 08030200 Hangs Excel

The following bug has been logged online:

Bug reference: 4361
Logged by: Jim Dornfeld
Email address: jim@alohacondos.com
PostgreSQL version: ODBC Driver
Operating system: Vista
Description: ODBC Driver 08030200 Hangs Excel
Details:

Using the 08030200 ODBC PostgreSQL driver with MS-Excel (2003) it freezes
Excel after importing a database query. Downgrading to 08030100 fixes the
hang and seems to work fine.

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

Re: [HACKERS] Replay attack of query cancel

Andrew Gierth wrote:

> There appears to be only one significant obstacle; since the query
> cancel message is received _after_ forking a new backend, there has to
> be some mechanism for recording the new value of N on success. This
> is obviously fairly easy in the EXEC_BACKEND case, but it seems quite
> intrusive a change to have the non-EXEC_BACKEND case use shared memory
> as well.

I think you should look at making the memory used for this shared in
both cases, EXEC_BACKEND and not. The only downside is that shared
memory usage will grow a bit on a minor release, but it'll be tiny. The
portability problems caused by any other trick you use to transmit the
value is probably going to be a lot harder.

> 2. The server accepts either the old-style or the secure cancel
> request from the client, but doesn't allow old-style requests
> once a valid secure request has been seen.

Hmm, I think there should be a way to turn off acceptance of old-style
without necessarily requiring a new-style request. Otherwise, how are
you protected from DoS if you have never sent a cancel request at all?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
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] Patch: plan invalidation vs stored procedures

Hi

We need plan invalidation fix in 8.3 also at least it would make migrating from 8.2 to 8.3 much more attractive.
Currenlty we are having problems related to plan invalidation couple of times per week (mainly we have to let developers change their code before we release it into live databases but it feels like sitting on ticking bomb after previous downtime).
Is it possible to get it into some official 8.3.x release or should we do it in house?
Who should add it into september commitfest?

Asko


On Fri, Aug 15, 2008 at 2:13 PM, Martin Pihlak <martin.pihlak@gmail.com> wrote:
Tom Lane wrote:
> Martin Pihlak <martin.pihlak@gmail.com> writes:
>> Changing statement result type is also currently prohibited in
>> StorePreparedStatement. There maybe good reasons for this,
>
> How about "the SQL spec says so"?
>
> Admittedly, it's a bit of a jump from views to prepared statements,
> but the spec is perfectly clear that altering a table doesn't alter
> any views dependent on it: SQL99 11.11 <add column definition> saith

As you said it is a bit of a jump ... For one thing view definitions are
persistent whereas statements are bound to be replanned sooner or later -
reconnects etc. Disallowing replanning after invalidation just postpones
it and meanwhile the cached plans are left unusable ("cached plan must not
change result"). IMHO the problem should be left for the application to handle.
Because this is where it will end up anyway.

Attached is a patch that implements plan invalidation on function DROP,
REPLACE and ALTER.  Function oids used by the query are collected in analyze phase
and stored in PlannedStmt. Only plans that reference the altered function are
invalidated. The patch also enables replanning on result set change.

regards,
Martin



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


Re: [DOCS] TODO build rule

Peter Eisentraut wrote:
> On Saturday 16 August 2008 03:22:09 Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > I tried building TODO.html from TODO according to the description in
> > > doc/src/FAQ/README, but saw the following kind of difference repeating:
>
> > > Apparently, there is a piece of code missing that adds these <em> tags
> > > around the done items. Bruce, do you have this code, and can you add it
> > > to the README?
> >
> > These two lines in pgsql/src/tools/TODO2html should be adding "*"s which
> > is then interpreted as "<em>":
>
> So there are two inconsistent sets of instructions for creating TODO.html, one
> in doc/src/FAQ/README and one in src/tools/TODO2html. Which one is being
> used?
>
> I want to convert the real one to a makefile, btw.

Oh, I forgot that README talked about making TODO.html. I have updated
the README to suggest using pgsql/src/tools/TODO2html.

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

[COMMITTERS] pgsql: Update instructions on generating TODO.html.

Log Message:
-----------
Update instructions on generating TODO.html.

Modified Files:
--------------
pgsql/doc/src/FAQ:
README (r1.3 -> r1.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/README?r1=1.3&r2=1.4)

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

[SQL] Cursor

hi guys...........
 
This my cursor
 
DECLARE
var varchar(15); 
  cursor1 CURSOR FOR select codigo_uni as codigo
            from recorrido
            where estado='V';
 
BEGIN
 open cursor1;
 
var=cursor1.codigo;
END;
 
It's almost 200 records,
but, I not unknow how read  record for record, I need found one record specific,
 
Excuse me  my english, no write nothing goog, I'm from ecuador.
 
Or explain how, I use the loop, while,  in my function declarated.
Please, more guides....
 
Thanks................

Re: [GENERAL] Changing between ORDER BY DESC and ORDER BY ASC

On Aug 15, 2008, at 12:35 PM, William Garrison wrote:
> Is there an easy way to write one single query that can alternate
> between ASC and DESC orders? Ex:
>
> CREATE OR REPLACE FUNCTION GetSomeStuff(_start integer, _count
> integer, _sortDesc boolean)
> RETURNS SETOF text AS
> $BODY$
> SELECT
> something
> FROM
> whatever
> WHERE
> whatever
> ORDER BY
> another_column
> OFFSET $1 LIMIT $2
> ($4 = true ? 'DESC' : 'ASC');
> $BODY$
> LANGUAGE 'sql' VOLATILE;
>
> I can think of a few ways, but I am hoping for something more elegant.
> 1) In my case another_column is numeric, so I could multiple by
> negative one if I want it in the other order. Not sure what this
> does to the optimizer if the column is indexed or not.

In my experience, it's pretty rare for an index to be used to satisfy
an ORDER BY.

> 2) I could write the statement twice, once with ASC and once with
> DESC, and then use IF/ELSE structure to pick one.
> 3) I could generate the statement dynamically.
>
> I am hoping there is some super secret extension that can handle
> this. This seems like one of those foolish things in SQL, where it
> is too declarative. ASC and DESC should be parameters to order by,
> not a part of the syntax. But I digress... any other suggestions?

None that I can think of, unfortunately. It might not be horribly
hard to allow plpgsql to use a variable for ASC vs DESC; that might
be your best bet.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Re: [GENERAL] Confronting the maximum column limitation

On Aug 12, 2008, at 3:15 PM, Jeff Gentry wrote:
> So I've seen the header file where the 1600 column limit is defined


IIRC, that limit is directly related to block size in the header, so
one possible fix is to increase block size. AFAIK anything up to 64K
blocks should be safe.

BTW, keep in mind that if you're storing anything that's a varlena
(anything that's variable length, including NUMBER) where you have
that many columns, every single varlena is going to end up toasted.
That's bound to have a *serious* performance impact.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Re: [PERFORM] Optimizing a VIEW

On Aug 15, 2008, at 1:36 PM, Madison Kelly wrote:
> The 'cust_id' references the customer that the given data belongs
> to. The reason for this "data bucket" (does this structure have a
> proper name?) is that the data I need to store on a give customer
> is quite variable and outside of my control. As it is, there is
> about 400 different variable/value pairs I need to store per customer.


It's called Entity-Attribute-Value, and it's performance is pretty
much guaranteed to suck for any kind of a large dataset. The problem
is that you're storing a MASSIVE amount of extra information for
every single value. Consider:

If each data point was just a field in a table, then even if we left
cd_value as text, each data point would consume 4 bytes* + 1 byte per
character (I'm assuming you don't need extra UTF8 chars or anything).
Of course if you know you're only storing numbers or the like then
you can make that even more efficient.

* In 8.3, the text field overhead could be as low as 1 byte if the
field is small enough.

OTOH, your table is going to 32+24 bytes per row just for the per-row
overhead, ints and timestamps. Each text field will have 1 or 4 bytes
in overhead, then you have to store the actual data. Realistically,
you're looking at 60+ bytes per data point, as opposed to maybe 15,
or even down to 4 if you know you're storing an int.

Now figure out what that turns into if you have 100 data points per
minute. It doesn't take very long until you have a huge pile of data
you're trying to deal with. (As an aside, I once consulted with a
company that wanted to do this... they wanted to store about 400 data
points from about 1000 devices on a 5 minute interval. That worked
out to something like 5GB per day, just for the EAV table. Just
wasn't going to scale...)

So, back to your situation... there's several things you can do that
will greatly improve things.

Identify data points that are very common and don't use EAV to store
them. Instead, store them as regular fields in a table (and don't use
text if at all possible).

You need to trim down your EAV table. Throw out the added/modified
info; there's almost certainly no reason to store that *per data
point*. Get rid of cd_id; there should be a natural PK you can use,
and you certainly don't want anything else referring to this table
(which is a big reason to use a surrogate key).

cd_variable and cd_tag need to be ints that point at other tables.
For that matter, do you really need to tag each *data point*?
Probably not...

Finally, if you have a defined set of points that you need to report
on, create a materialized view that has that information.

BTW, it would probably be better to store data either in the main
table, or the history table, but not both places.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Re: [SQL] Cursor

Xavier Bermeo wrote:
> Hi, guys.......
>
> I have problems with cursosrs.
>
> Anyone have an example complete the how load and read each position
> of a cursor?
>
> I wait your answer........
>
> Thanks.......guys

Assuming you're using ECPG, there are a couple of examples in the
documentation, e.g.,

http://www.postgresql.org/docs/8.3/static/ecpg-commands.html
(see Select using cursors:

http://www.postgresql.org/docs/8.3/static/ecpg-variables.html#AEN33442

The essence is you DECLARE the cursor, OPEN it and then FETCH rows in
some kind of loop, and finish by CLOSE cursor. To exit the loop, you
can check sqlca.sqlcode for 100 (NOT FOUND) or a SQLSTATE of 02000.

Joe

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

Re: [PERFORM] Filesystem benchmarking for pg 8.3.3 server

On Aug 13, 2008, at 2:54 PM, Henrik wrote:
>> Additionally, you need to be careful of what size writes you're
>> using. If you're doing random writes that perfectly align with the
>> raid stripe size, you'll see virtually no RAID5 overhead, and
>> you'll get the performance of N-1 drives, as opposed to RAID10
>> giving you N/2.
> But it still needs to do 2 reads and 2 writes for every write,
> correct?


If you are completely over-writing an entire stripe, there's no
reason to read the existing data; you would just calculate the parity
information from the new data. Any good controller should take that
approach.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Re: [pgsql-es-ayuda] Postgres Vs. MySQL

Saludos

Aprovechando que estamos discutiendo las bondades de PostgreSQL, recientemente escribí a esta lista preguntando por el estado de los sistemas de replicación en PostgreSQL. He consultado documentación de Slony, Bucardo y otros, pero no lo veo lo suficientemente intuitivo tal como lo hace MySQL.

Igualmente, me gustaría cual es el proyecto de replicación más estable hasta el momento y que reproduzca el mismo esquema que permite MySQL : un master - N esclavos. He visto que Slony es capaz pero también me han dicho que es una tortura el mantenimiento de un esquema con dicho sistema.

En las listas de desarrolladores hay un tremendo debate acerca de qué sistema incorporar en el Core de PostgreSQl, si debe ser síncrono-asíncrono, etc... teniendo en cuenta que pueden pasar 1 o 2 años antes de que esté disponible y sea fiable, me gustaría empezar a probar los otros sistemas.

Alguna indicación, experiencia o algo que añadir?

Gracias

2008/8/16 Marco Castillo <mabcastillo@gmail.com>
Pues yo por lo siguiente:
- Es libre
- Es una bd relacional muy completa (stored procedures, integridad referencial, table spaces, particionamiento con reglas, etc) y algunos features solamente los encuentras en bds muy costosas.
- Muy buen soporte (qué mejor que estas listas y las listas en inglés?)
- Es rápida
- Una bd madura.

En mi empresa trabajamos también con MySQL, pero MySQL hasta en épocas recientes ha introducido conceptos que en PostgreSQL hace mucho que están y ya son muy maduros.

Saludos


2008/8/15 Rubén F. Santiago <rfs1986@gmail.com>
Hola amigos de la lista, ¿qué tal?
 
Os escribo para enviaros una pregunta "especial". No es ningún problema de soporte ni nada por el estilo; tampoco escribo con ánimo de crear un debate, ni mucho menos.
 
Me gustaría saber por qué sois usuarios de Postgres y no de MySQL.
 
Yo también soy usuario de postgres; manejé MySQL y no tiene punto de comparación. Pero me gustaría saber vuestra opinión Guiño icono gestual
 
Un saludo




--
Xavier Vidal Piera
Enginyer Tècnic Informàtic de Gestió
Tècnic Especialista Informàtic d'equips
xavividal@gmail.com
http://web.xaviervidal.net
610.68.41.78

Re: [PERFORM] Experiences storing binary in Postgres

On Aug 14, 2008, at 1:00 PM, juliano.freitas@ati.pe.gov.br wrote:
> We're developing a project which uses PostgreSQL to store binary
> documents. Since our system is likely to grow up to some terabytes
> in two
> years, I'd like to ask if some of you have had some experience with
> storing a huge amount of blob files in postgres. How does it scale in
> performance?

It depends on your access patterns. If this is an OLTP database, you
need to think really hard about putting that stuff in the database,
because it will seriously hurt your caching ability. If we had the
ability to define buffersize limits per-tablespace, you could handle
it that way, but...

Another consideration is why you want to put this data in a database
in the first place? It may be convenient, but if that's the only
reason you could be hurting yourself in the long run.

BTW, after seeing the SkyTools presentation at pgCon this year I
realized there's a pretty attractive middle-ground between storing
this data in your production database and storing it in the
filesystem. Using plproxy and pgBouncer, it wouldn't be hard to store
the data in an external database. That gives you the ease-of-
management of a database, but keeps the data away from your
production data.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Re: [pgsql-es-ayuda] Postgres Vs. MySQL

Pues yo por lo siguiente:
- Es libre
- Es una bd relacional muy completa (stored procedures, integridad referencial, table spaces, particionamiento con reglas, etc) y algunos features solamente los encuentras en bds muy costosas.
- Muy buen soporte (qué mejor que estas listas y las listas en inglés?)
- Es rápida
- Una bd madura.

En mi empresa trabajamos también con MySQL, pero MySQL hasta en épocas recientes ha introducido conceptos que en PostgreSQL hace mucho que están y ya son muy maduros.

Saludos


2008/8/15 Rubén F. Santiago <rfs1986@gmail.com>
Hola amigos de la lista, ¿qué tal?
 
Os escribo para enviaros una pregunta "especial". No es ningún problema de soporte ni nada por el estilo; tampoco escribo con ánimo de crear un debate, ni mucho menos.
 
Me gustaría saber por qué sois usuarios de Postgres y no de MySQL.
 
Yo también soy usuario de postgres; manejé MySQL y no tiene punto de comparación. Pero me gustaría saber vuestra opinión Guiño icono gestual
 
Un saludo

Re: [GENERAL] How to tell if a trigger is disabled

On Fri, Aug 15, 2008 at 5:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Ian Harding" <harding.ian@gmail.com> writes:
>> Is there any way to tell if a trigger or triggers are disabled on a
>> table? I was updating some data a week or two ago and must have
>> forgotten to re-enable the triggers. Took me a little while to figure
>> out. \d tablename didn't tell me, nor did \d+ tablename.
>
>> This is on 8.2.3.
>
> FWIW, 8.3's psql knows about showing this in \dt.
>
Yet another reason to upgrade.. Thanks!

- Ian

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

Re: [PERFORM] Incorrect estimates on correlated filters

On Aug 13, 2008, at 1:45 PM, Chris Kratz wrote:
> Yes, I know hints are frowned upon around here. Though, I'd love
> to have them or something equivalent on this particular query just
> so the customer can run their important reports. As it is, it's
> unrunnable.


Actually, now that I think about it the last time this was brought up
there was discussion about something that doesn't force a particular
execution method, but instead provides improved information to the
planner. It might be worth pursuing that, as I think there was less
opposition to it.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Re: [HACKERS] Replay attack of query cancel

>>>>> "Magnus" == Magnus Hagander <magnus@hagander.net> writes:

[snip]

I'm looking (at Magnus' suggestion) at implementing this.

There appears to be only one significant obstacle; since the query
cancel message is received _after_ forking a new backend, there has to
be some mechanism for recording the new value of N on success. This
is obviously fairly easy in the EXEC_BACKEND case, but it seems quite
intrusive a change to have the non-EXEC_BACKEND case use shared memory
as well.

I can think of a couple of other ways to do it (e.g. some standard
Unix pipe tricks) but I'm not sure of what portability assumptions are
usually made. (I'm assuming that Windows always uses EXEC_BACKEND.)
Ideas?

(To sum up the previous discussion, this is the proposal as I understand
it so far:

1. Servers that support secure cancels will report secure_cancel_key in
the startup GUC settings; the value of this key is just randomness
(presumably in hex for convenience).

2. The server accepts either the old-style or the secure cancel
request from the client, but doesn't allow old-style requests
once a valid secure request has been seen.

3. The client doesn't send secure cancel requests unless
secure_cancel_key was reported. The client may or may not choose
to send secure cancels based on whether SSL is in use; we can
leave this decision up to the client in general, even if we make
libpq use secure cancels only in the SSL case.

The upshot is that replay protection is automatically available if
both the client and server support it, and the client chooses to use it.
The net protocol change is one new GUC and one new message format for
the cancel message.)

--
Andrew.

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

Re: [HACKERS] proposal sql: labeled function params

On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote:
>> "value AS name", on the other hand, accomplishes the same in a more
>> SQL-looking fashion with no new reserved word (since AS is already
>> fully reserved).
>
> would it be more natural / SQL-like to use "value AS name" or "name AS
> value" ?


IMHO, *natural* would be name *something* value, because that's how
every other language I've seen does it.

SQL-like would be value AS name, but I'm not a fan of putting the
value before the name. And I think value AS name will just lead to a
ton of confusion.

Since I think it'd be very unusual to do a => (b => c), I'd vote that
we just go with =>. Anyone trying to do a => b => c should
immediately question if that would work.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Re: [DOCS] TODO build rule

On Saturday 16 August 2008 03:22:09 Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > I tried building TODO.html from TODO according to the description in
> > doc/src/FAQ/README, but saw the following kind of difference repeating:

> > Apparently, there is a piece of code missing that adds these <em> tags
> > around the done items. Bruce, do you have this code, and can you add it
> > to the README?
>
> These two lines in pgsql/src/tools/TODO2html should be adding "*"s which
> is then interpreted as "<em>":

So there are two inconsistent sets of instructions for creating TODO.html, one
in doc/src/FAQ/README and one in src/tools/TODO2html. Which one is being
used?

I want to convert the real one to a makefile, btw.

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

Re: [HACKERS] [PgFoundry] Unsigned Data Types

On Aug 15, 2008, at 1:00 AM, Ryan Bradetich wrote:
> Here is the first pass at the unsigned data type I have been
> working on.
>
> I am planning on adding these to the September 2008 commitfest wiki
> page.
> The unsigned data type is not targeted for core, but for the uint
> PgFoundry project.


Is the intention for the types to go into pg_catalog? It'd be nice if
you could specify what schema they should be installed in. An
uninstall would also be good.

Thanks for doing this, I've wished we had uint types in the past, and
I'm sure I will again in the future!
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

[SQL] Cursor

Hi, guys.......
 
I have  problems with cursosrs.
 
Anyone have an example complete the how  load and read each position of a cursor?
 
I wait your answer........
 
Thanks.......guys

Re: [HACKERS] proposal sql: labeled function params

On Sat, 2008-08-16 at 08:44 +0200, Pavel Stehule wrote:
> Hello

> >> "value AS name", on the other hand, accomplishes the same in a more
> >> SQL-looking fashion with no new reserved word (since AS is already
> >> fully reserved).
> >
> > would it be more natural / SQL-like to use "value AS name" or "name AS
> > value" ?
> >
>
> it's question, because SQL wit AS clause don't specify value, it
> specifies label.

A "label" is the same thing as "variable"/"attribute"/"argument name" in
all programming languages I can think of. Why do you need two kinds of
argument names in postgreSQL ?

maybe you are after something like keyword arguments in python ?

http://docs.python.org/tut/node6.html#SECTION006720000000000000000

keyword arguments are a way of saying that you don't know all variable
names (or "labels" if you prefer) at function defining time and are
going to pass them in when calling.

It's kind of extended variadic argument, only with names and types for
each extra arg.

Of course we could extend this to have shortcut of passing in original
variable or field names automatically, without you having to explicitly
write it down that is fun(name) instead of fun(name=name) but I'm not
sure it is actually a good idea. SQL in general has not been very terse
language.

But I sure would like to have the flexibility of keyword arguments in
PostgreSQL .


> Regards
> Pavel
>
>
> > -------------
> > Hannu
> >
> >
> >


--
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] proposal sql: labeled function params

On Saturday 16 August 2008 09:38:41 Pavel Stehule wrote:
> because you have to write labels, where labels are equal with column
> names. I would to add same comfort like SQL/XML functions.

Just a thought: You might be able to design this in some way to work on top of
named parameter calling. Define a function with variadic arguments and allow
passing arbitrary parameter names. Before you can use that to implement
xmlforest in user space you need to work out the issue of passing arbitrary
argument types. But that is also something that would be interesting for
other purposes.

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

Re: [pgadmin-hackers] pgScript patch based on pgScript-1.0-beta-3

2008/8/16 Erikjan Rijkers <er@xs4all.nl>:
> No.
>
> In the regular query tool one can draw a select block (with mouse or
> keyboard). Subsequently pressing F5 *only* executes the selected text. This
> is a very handy behaviour that (I think) could be mimicked by pgscript without
> problem.
> (it makes it easy to quickly test parts of a larger script.)
>

All right. I need to stop the development of pgScript until it is
approved (and I hope integraed) by pgAdmin. But then I put that as the
first item of the TODO list.

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

Re: [INTERFACES] ecpg 'set' failure using host vars

Sorry about the 'false start' before. :-(

Tom Lane wrote:
> Michael Meskes <meskes@postgresql.org> writes:
>> Without checking the sources it seems as if PQexecParams is not able
> to handle a parameter in a set command. Can anyone confirm this?
>
> The backend only supports parameters in plannable statements, ie
> SELECT/INSERT/UPDATE/DELETE. (Possibly DECLARE CURSOR, I'm too
> lazy to check.)

Thanks for the hint guys. I used a prepare/execute pair instead and
it worked a treat. More cumbersome but it gets the job done.

Thanks again.

Bosco.

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

Re: [INTERFACES] ecpg 'set' failure using host vars

Tom Lane wrote:
> Michael Meskes <meskes@postgresql.org> writes:
>> Without checking the sources it seems as if PQexecParams is not able to handle a parameter in a set command. Can anyone confirm this?
>
> The backend only supports parameters in plannable statements, ie
> SELECT/INSERT/UPDATE/DELETE. (Possibly DECLARE CURSOR, I'm too
> lazy to check.)
>
> regards, tom lane
>

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

Re: [HACKERS] Parsing of pg_hba.conf and authentication inconsistencies

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Other than that, it moves code around to do the parsing in the
>> postmaster and the maching in the backend.
>
> How does that work in EXEC_BACKEND environments?

(Not tested yet, still on my TODO, but still)

It will parse the file in the postmaster *and* in the backend. Thus, the
safety that it won't reload on a broken file actually won't work since
backends reload the configuration everytime they start, but you will
still get the error/warning on reload.

//Magnus


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

Re: [pgadmin-hackers] pgScript patch based on pgScript-1.0-beta-3

On Sat, August 16, 2008 15:55, Mickael Deloison wrote:
> 2008/8/14 Erikjan Rijkers <er@xs4all.nl>:
>> 1) It would be nice if pgScript would only execute a select-block, like the
>> normal pgAdmin querytool does.
>
> Do you mean: redirecting a pgScript script to the regular query tool
> if both the pgScript button is pressed and the edit window contains
> only a select statement?

No.

In the regular query tool one can draw a select block (with mouse or
keyboard). Subsequently pressing F5 *only* executes the selected text. This
is a very handy behaviour that (I think) could be mimicked by pgscript without
problem.
(it makes it easy to quickly test parts of a larger script.)

>> 2) The example script from the url above says:
>> IF (SELECT 1 FROM table) -- Then table exists

> You're right, with a count(*) it returns something (0 if no rows) and
> this is true.

Right, thanks.

>> 3) When the BEGIN - END block fails, pgScript executes the ELSE block.
>> This
>> seems questionable behaviour, no? It can be seen with that same
> I do not understand this observation. Could you be more precise please?

Upon consideration, I might have been mistaken; I'll test again and look for
a clearly reproducible case.

thanks,

Erikjan


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

Re: [INTERFACES] ecpg 'set' failure using host vars

Michael Meskes <meskes@postgresql.org> writes:
> Without checking the sources it seems as if PQexecParams is not able to handle a parameter in a set command. Can anyone confirm this?

The backend only supports parameters in plannable statements, ie
SELECT/INSERT/UPDATE/DELETE. (Possibly DECLARE CURSOR, I'm too
lazy to check.)

regards, tom lane

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

Re: [HACKERS] proposal sql: labeled function params

"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> or just use := operator?

You're still commandeering an operator name that wasn't reserved before.
This one doesn't even have the feeble excuse of being Oracle-compatible.

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] Parsing of pg_hba.conf and authentication inconsistencies

Magnus Hagander <magnus@hagander.net> writes:
> Other than that, it moves code around to do the parsing in the
> postmaster and the maching in the backend.

How does that work in EXEC_BACKEND environments?

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] Parsing of pg_hba.conf and authentication inconsistencies

Index: src/backend/libpq/auth.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.167
diff -c -r1.167 auth.c
*** src/backend/libpq/auth.c 1 Aug 2008 11:41:12 -0000 1.167
--- src/backend/libpq/auth.c 16 Aug 2008 15:44:20 -0000
***************
*** 211,217 ****
if (status == STATUS_EOF)
proc_exit(0);

! switch (port->auth_method)
{
case uaReject:
errstr = gettext_noop("authentication failed for user \"%s\": host rejected");
--- 211,217 ----
if (status == STATUS_EOF)
proc_exit(0);

! switch (port->hba->auth_method)
{
case uaReject:
errstr = gettext_noop("authentication failed for user \"%s\": host rejected");
***************
*** 279,285 ****
errmsg("missing or erroneous pg_hba.conf file"),
errhint("See server log for details.")));

! switch (port->auth_method)
{
case uaReject:

--- 279,285 ----
errmsg("missing or erroneous pg_hba.conf file"),
errhint("See server log for details.")));

! switch (port->hba->auth_method)
{
case uaReject:

***************
*** 1761,1767 ****
/*
* Determine the username of the initiator of the connection described
* by "port". Then look in the usermap file under the usermap
! * port->auth_arg and see if that user is equivalent to Postgres user
* port->user.
*
* Return STATUS_OK if yes, STATUS_ERROR if no match (or couldn't get info).
--- 1761,1767 ----
/*
* Determine the username of the initiator of the connection described
* by "port". Then look in the usermap file under the usermap
! * port->hba->usermap and see if that user is equivalent to Postgres user
* port->user.
*
* Return STATUS_OK if yes, STATUS_ERROR if no match (or couldn't get info).
***************
*** 1799,1805 ****
(errmsg("Ident protocol identifies remote user as \"%s\"",
ident_user)));

! if (check_ident_usermap(port->auth_arg, port->user_name, ident_user))
return STATUS_OK;
else
return STATUS_ERROR;
--- 1799,1805 ----
(errmsg("Ident protocol identifies remote user as \"%s\"",
ident_user)));

! if (check_ident_usermap(port->hba->usermap, port->user_name, ident_user))
return STATUS_OK;
else
return STATUS_ERROR;
Index: src/backend/libpq/crypt.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/libpq/crypt.c,v
retrieving revision 1.74
diff -c -r1.74 crypt.c
*** src/backend/libpq/crypt.c 1 Jan 2008 19:45:49 -0000 1.74
--- src/backend/libpq/crypt.c 16 Aug 2008 15:44:20 -0000
***************
*** 54,60 ****
return STATUS_ERROR;

/* We can't do crypt with MD5 passwords */
! if (isMD5(shadow_pass) && port->auth_method == uaCrypt)
{
ereport(LOG,
(errmsg("cannot use authentication method \"crypt\" because password is MD5-encrypted")));
--- 54,60 ----
return STATUS_ERROR;

/* We can't do crypt with MD5 passwords */
! if (isMD5(shadow_pass) && port->hba->auth_method == uaCrypt)
{
ereport(LOG,
(errmsg("cannot use authentication method \"crypt\" because password is MD5-encrypted")));
***************
*** 65,71 ****
* Compare with the encrypted or plain password depending on the
* authentication method being used for this connection.
*/
! switch (port->auth_method)
{
case uaMD5:
crypt_pwd = palloc(MD5_PASSWD_LEN + 1);
--- 65,71 ----
* Compare with the encrypted or plain password depending on the
* authentication method being used for this connection.
*/
! switch (port->hba->auth_method)
{
case uaMD5:
crypt_pwd = palloc(MD5_PASSWD_LEN + 1);
***************
*** 155,161 ****
}
}

! if (port->auth_method == uaMD5)
pfree(crypt_pwd);
if (crypt_client_pass != client_pass)
pfree(crypt_client_pass);
--- 155,161 ----
}
}

! if (port->hba->auth_method == uaMD5)
pfree(crypt_pwd);
if (crypt_client_pass != client_pass)
pfree(crypt_client_pass);
Index: src/backend/libpq/hba.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/libpq/hba.c,v
retrieving revision 1.166
diff -c -r1.166 hba.c
*** src/backend/libpq/hba.c 1 Aug 2008 09:09:49 -0000 1.166
--- src/backend/libpq/hba.c 16 Aug 2008 15:44:20 -0000
***************
*** 41,48 ****

#define MAX_TOKEN 256

/*
! * These variables hold the pre-parsed contents of the hba and ident
* configuration files, as well as the flat auth file.
* Each is a list of sublists, one sublist for
* each (non-empty, non-comment) line of the file. Each sublist's
--- 41,51 ----

#define MAX_TOKEN 256

+ /* pre-parsed content of HBA config file */
+ static List *parsed_hba_lines = NIL;
+
/*
! * These variables hold the pre-parsed contents of the ident
* configuration files, as well as the flat auth file.
* Each is a list of sublists, one sublist for
* each (non-empty, non-comment) line of the file. Each sublist's
***************
*** 52,61 ****
* one token, since blank lines are not entered in the data structure.
*/

- /* pre-parsed content of HBA config file and corresponding line #s */
- static List *hba_lines = NIL;
- static List *hba_line_nums = NIL;
-
/* pre-parsed content of ident usermap file and corresponding line #s */
static List *ident_lines = NIL;
static List *ident_line_nums = NIL;
--- 55,60 ----
***************
*** 566,696 ****


/*
! * Scan the rest of a host record (after the mask field)
! * and return the interpretation of it as *userauth_p, *auth_arg_p, and
! * *error_p. *line_item points to the next token of the line, and is
! * advanced over successfully-read tokens.
*/
! static void
! parse_hba_auth(ListCell **line_item, UserAuth *userauth_p,
! char **auth_arg_p, bool *error_p)
! {
! char *token;
!
! *auth_arg_p = NULL;
!
! if (!*line_item)
! {
! *error_p = true;
! return;
! }
!
! token = lfirst(*line_item);
! if (strcmp(token, "trust") == 0)
! *userauth_p = uaTrust;
! else if (strcmp(token, "ident") == 0)
! *userauth_p = uaIdent;
! else if (strcmp(token, "password") == 0)
! *userauth_p = uaPassword;
! else if (strcmp(token, "krb5") == 0)
! *userauth_p = uaKrb5;
! else if (strcmp(token, "gss") == 0)
! *userauth_p = uaGSS;
! else if (strcmp(token, "sspi") == 0)
! *userauth_p = uaSSPI;
! else if (strcmp(token, "reject") == 0)
! *userauth_p = uaReject;
! else if (strcmp(token, "md5") == 0)
! *userauth_p = uaMD5;
! else if (strcmp(token, "crypt") == 0)
! *userauth_p = uaCrypt;
! #ifdef USE_PAM
! else if (strcmp(token, "pam") == 0)
! *userauth_p = uaPAM;
! #endif
! #ifdef USE_LDAP
! else if (strcmp(token, "ldap") == 0)
! *userauth_p = uaLDAP;
! #endif
! else
! {
! *error_p = true;
! return;
! }
! *line_item = lnext(*line_item);
!
! /* Get the authentication argument token, if any */
! if (*line_item)
! {
! token = lfirst(*line_item);
! *auth_arg_p = pstrdup(token);
! *line_item = lnext(*line_item);
! /* If there is more on the line, it is an error */
! if (*line_item)
! *error_p = true;
! }
! }
!
!
! /*
! * Process one line from the hba config file.
! *
! * See if it applies to a connection from a host with IP address port->raddr
! * to a database named port->database. If so, return *found_p true
! * and fill in the auth arguments into the appropriate port fields.
! * If not, leave *found_p as it was. If the record has a syntax error,
! * return *error_p true, after issuing a message to the log. If no error,
! * leave *error_p as it was.
! */
! static void
! parse_hba(List *line, int line_num, hbaPort *port,
! bool *found_p, bool *error_p)
{
char *token;
- char *db;
- char *role;
struct addrinfo *gai_result;
struct addrinfo hints;
int ret;
- struct sockaddr_storage addr;
- struct sockaddr_storage mask;
char *cidr_slash;
ListCell *line_item;

line_item = list_head(line);
/* Check the record type. */
token = lfirst(line_item);
if (strcmp(token, "local") == 0)
{
! /* Get the database. */
! line_item = lnext(line_item);
! if (!line_item)
! goto hba_syntax;
! db = lfirst(line_item);
!
! /* Get the role. */
! line_item = lnext(line_item);
! if (!line_item)
! goto hba_syntax;
! role = lfirst(line_item);
!
! line_item = lnext(line_item);
! if (!line_item)
! goto hba_syntax;
!
! /* Read the rest of the line. */
! parse_hba_auth(&line_item, &port->auth_method,
! &port->auth_arg, error_p);
! if (*error_p)
! goto hba_syntax;
!
! /* Disallow auth methods that always need TCP/IP sockets to work */
! if (port->auth_method == uaKrb5)
! goto hba_syntax;
!
! /* Does not match if connection isn't AF_UNIX */
! if (!IS_AF_UNIX(port->raddr.addr.ss_family))
! return;
}
else if (strcmp(token, "host") == 0
|| strcmp(token, "hostssl") == 0
--- 565,593 ----


/*
! * Parse one line in the hba config file and store the result in
! * a HbaLine structure.
*/
! static bool
! parse_hba_line(List *line, int line_num, HbaLine *parsedline)
{
char *token;
struct addrinfo *gai_result;
struct addrinfo hints;
int ret;
char *cidr_slash;
+ char *unsupauth;
ListCell *line_item;

line_item = list_head(line);
+
+ parsedline->linenumber = line_num;
+
/* Check the record type. */
token = lfirst(line_item);
if (strcmp(token, "local") == 0)
{
! parsedline->conntype = ctLocal;
}
else if (strcmp(token, "host") == 0
|| strcmp(token, "hostssl") == 0
***************
*** 700,713 ****
if (token[4] == 's') /* "hostssl" */
{
#ifdef USE_SSL
! /* Record does not match if we are not on an SSL connection */
! if (!port->ssl)
! return;
!
! /* Placeholder to require specific SSL level, perhaps? */
! /* Or a client certificate */
!
! /* Since we were on SSL, proceed as with normal 'host' mode */
#else
/* We don't accept this keyword at all if no SSL support */
goto hba_syntax;
--- 597,603 ----
if (token[4] == 's') /* "hostssl" */
{
#ifdef USE_SSL
! parsedline->conntype = ctHostSSL;
#else
/* We don't accept this keyword at all if no SSL support */
goto hba_syntax;
***************
*** 716,744 ****
#ifdef USE_SSL
else if (token[4] == 'n') /* "hostnossl" */
{
! /* Record does not match if we are on an SSL connection */
! if (port->ssl)
! return;
}
#endif

! /* Get the database. */
! line_item = lnext(line_item);
! if (!line_item)
! goto hba_syntax;
! db = lfirst(line_item);

! /* Get the role. */
! line_item = lnext(line_item);
! if (!line_item)
! goto hba_syntax;
! role = lfirst(line_item);

/* Read the IP address field. (with or without CIDR netmask) */
line_item = lnext(line_item);
if (!line_item)
goto hba_syntax;
! token = lfirst(line_item);

/* Check if it has a CIDR suffix and if so isolate it */
cidr_slash = strchr(token, '/');
--- 606,642 ----
#ifdef USE_SSL
else if (token[4] == 'n') /* "hostnossl" */
{
! parsedline->conntype = ctHostNoSSL;
}
#endif
+ else
+ {
+ /* "host", or "hostnossl" and SSL support not built in */
+ parsedline->conntype = ctHost;
+ }
+ } /* record type */
+ else
+ goto hba_syntax;

! /* Get the database. */
! line_item = lnext(line_item);
! if (!line_item)
! goto hba_syntax;
! parsedline->database = pstrdup(lfirst(line_item));

! /* Get the role. */
! line_item = lnext(line_item);
! if (!line_item)
! goto hba_syntax;
! parsedline->role = pstrdup(lfirst(line_item));

+ if (parsedline->conntype != ctLocal)
+ {
/* Read the IP address field. (with or without CIDR netmask) */
line_item = lnext(line_item);
if (!line_item)
goto hba_syntax;
! token = pstrdup(lfirst(line_item));

/* Check if it has a CIDR suffix and if so isolate it */
cidr_slash = strchr(token, '/');
***************
*** 760,768 ****
{
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
! errmsg("invalid IP address \"%s\" in file \"%s\" line %d: %s",
! token, HbaFileName, line_num,
! gai_strerror(ret))));
if (cidr_slash)
*cidr_slash = '/';
if (gai_result)
--- 658,666 ----
{
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
! errmsg("invalid IP address \"%s\" in file \"%s\" line %d: %s",
! token, HbaFileName, line_num,
! gai_strerror(ret))));
if (cidr_slash)
*cidr_slash = '/';
if (gai_result)
***************
*** 773,786 ****
if (cidr_slash)
*cidr_slash = '/';

! memcpy(&addr, gai_result->ai_addr, gai_result->ai_addrlen);
pg_freeaddrinfo_all(hints.ai_family, gai_result);

/* Get the netmask */
if (cidr_slash)
{
! if (pg_sockaddr_cidr_mask(&mask, cidr_slash + 1,
! addr.ss_family) < 0)
goto hba_syntax;
}
else
--- 671,684 ----
if (cidr_slash)
*cidr_slash = '/';

! memcpy(&parsedline->addr, gai_result->ai_addr, gai_result->ai_addrlen);
pg_freeaddrinfo_all(hints.ai_family, gai_result);

/* Get the netmask */
if (cidr_slash)
{
! if (pg_sockaddr_cidr_mask(&parsedline->mask, cidr_slash + 1,
! parsedline->addr.ss_family) < 0)
goto hba_syntax;
}
else
***************
*** 796,813 ****
{
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
! errmsg("invalid IP mask \"%s\" in file \"%s\" line %d: %s",
! token, HbaFileName, line_num,
! gai_strerror(ret))));
if (gai_result)
pg_freeaddrinfo_all(hints.ai_family, gai_result);
goto hba_other_error;
}

! memcpy(&mask, gai_result->ai_addr, gai_result->ai_addrlen);
pg_freeaddrinfo_all(hints.ai_family, gai_result);

! if (addr.ss_family != mask.ss_family)
{
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
--- 694,711 ----
{
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
! errmsg("invalid IP mask \"%s\" in file \"%s\" line %d: %s",
! token, HbaFileName, line_num,
! gai_strerror(ret))));
if (gai_result)
pg_freeaddrinfo_all(hints.ai_family, gai_result);
goto hba_other_error;
}

! memcpy(&parsedline->mask, gai_result->ai_addr, gai_result->ai_addrlen);
pg_freeaddrinfo_all(hints.ai_family, gai_result);

! if (parsedline->addr.ss_family != parsedline->mask.ss_family)
{
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
***************
*** 816,877 ****
goto hba_other_error;
}
}

! if (addr.ss_family != port->raddr.addr.ss_family)
{
! /*
! * Wrong address family. We allow only one case: if the file has
! * IPv4 and the port is IPv6, promote the file address to IPv6 and
! * try to match that way.
! */
! #ifdef HAVE_IPV6
! if (addr.ss_family == AF_INET &&
! port->raddr.addr.ss_family == AF_INET6)
{
! pg_promote_v4_to_v6_addr(&addr);
! pg_promote_v4_to_v6_mask(&mask);
}
else
- #endif /* HAVE_IPV6 */
{
! /* Line doesn't match client port, so ignore it. */
! return;
}
}
-
- /* Ignore line if client port is not in the matching addr range. */
- if (!pg_range_sockaddr(&port->raddr.addr, &addr, &mask))
- return;
-
- /* Read the rest of the line. */
- line_item = lnext(line_item);
- if (!line_item)
- goto hba_syntax;
- parse_hba_auth(&line_item, &port->auth_method,
- &port->auth_arg, error_p);
- if (*error_p)
- goto hba_syntax;
}
! else
! goto hba_syntax;
!
! /* Does the entry match database and role? */
! if (!check_db(port->database_name, port->user_name, db))
! return;
! if (!check_role(port->user_name, role))
! return;
!
! /* Success */
! *found_p = true;
! return;

hba_syntax:
if (line_item)
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
! errmsg("invalid entry in file \"%s\" at line %d, token \"%s\"",
! HbaFileName, line_num,
! (char *) lfirst(line_item))));
else
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
--- 714,841 ----
goto hba_other_error;
}
}
+ } /* != ctLocal */
+
+ /* Get the authentication method */
+ line_item = lnext(line_item);
+ if (!line_item)
+ goto hba_syntax;
+ token = lfirst(line_item);
+
+ unsupauth = NULL;
+ if (strcmp(token, "trust") == 0)
+ parsedline->auth_method = uaTrust;
+ else if (strcmp(token, "ident") == 0)
+ parsedline->auth_method = uaIdent;
+ else if (strcmp(token, "password") == 0)
+ parsedline->auth_method = uaPassword;
+ else if (strcmp(token, "krb5") == 0)
+ #ifdef KRB5
+ parsedline->auth_method = uaKrb5;
+ #else
+ unsupauth = "krb5";
+ #endif
+ else if (strcmp(token, "gss") == 0)
+ #ifdef ENABLE_GSS
+ parsedline->auth_method = uaGSS;
+ #else
+ unsupauth = "gss";
+ #endif
+ else if (strcmp(token, "sspi") == 0)
+ #ifdef ENABLE_SSPI
+ parsedline->auth_method = uaSSPI;
+ #else
+ unsupauth = "sspi";
+ #endif
+ else if (strcmp(token, "reject") == 0)
+ parsedline->auth_method = uaReject;
+ else if (strcmp(token, "md5") == 0)
+ parsedline->auth_method = uaMD5;
+ else if (strcmp(token, "crypt") == 0)
+ parsedline->auth_method = uaCrypt;
+ else if (strcmp(token, "pam") == 0)
+ #ifdef USE_PAM
+ parsedline->auth_method = uaPAM;
+ #else
+ unsupauth = "pam";
+ #endif
+ else if (strcmp(token, "ldap") == 0)
+ #ifdef USE_LDAP
+ parsedline->auth_method = uaLDAP;
+ #else
+ unsupauth = "ldap";
+ #endif
+ else
+ {
+ ereport(LOG,
+ (errcode(ERRCODE_CONFIG_FILE_ERROR),
+ errmsg("invalid authentication method \"%s\" in file \"%s\" line %d",
+ token, HbaFileName, line_num)));
+ goto hba_other_error;
+ }
+
+ if (unsupauth)
+ {
+ ereport(LOG,
+ (errcode(ERRCODE_CONFIG_FILE_ERROR),
+ errmsg("invalid authentication method \"%s\" in file \"%s\" line %d: not supported on this platform",
+ token, HbaFileName, line_num)));
+ goto hba_other_error;
+ }
+
+ /* Invalid authentication combinations */
+ if (parsedline->conntype == ctLocal &&
+ parsedline->auth_method == uaKrb5)
+ {
+ ereport(LOG,
+ (errcode(ERRCODE_CONFIG_FILE_ERROR),
+ errmsg("krb5 authentication is not supported on local sockets in file \"%s\" line %d",
+ HbaFileName, line_num)));
+ goto hba_other_error;
+ }
+
+ /* Get the authentication argument token, if any */
+ line_item = lnext(line_item);
+ if (line_item)
+ {
+ token = lfirst(line_item);
+ parsedline->auth_arg= pstrdup(token);
+ }

! /*
! * backwards compatible format of ident authentication - support "naked" ident map
! * name, as well as "sameuser"/"samerole"
! */
! if (parsedline->auth_method == uaIdent)
! {
! if (parsedline->auth_arg && strlen(parsedline->auth_arg))
{
! if (strcmp(parsedline->auth_arg, "sameuser\n") == 0 ||
! strcmp(parsedline->auth_arg, "samerole\n") == 0)
{
! /* This is now the default */
! pfree(parsedline->auth_arg);
! parsedline->auth_arg = NULL;
! parsedline->usermap = NULL;
}
else
{
! /* Specific ident map specified */
! parsedline->usermap = parsedline->auth_arg;
! parsedline->auth_arg = NULL;
}
}
}
!
! return true;

hba_syntax:
if (line_item)
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
! errmsg("invalid entry in file \"%s\" at line %d, token \"%s\"",
! HbaFileName, line_num,
! (char *) lfirst(line_item))));
else
ereport(LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
***************
*** 880,886 ****

/* Come here if suitable message already logged */
hba_other_error:
! *error_p = true;
}


--- 844,850 ----

/* Come here if suitable message already logged */
hba_other_error:
! return false;
}


***************
*** 891,918 ****
static bool
check_hba(hbaPort *port)
{
- bool found_entry = false;
- bool error = false;
ListCell *line;
! ListCell *line_num;

! forboth(line, hba_lines, line_num, hba_line_nums)
{
! parse_hba(lfirst(line), lfirst_int(line_num),
! port, &found_entry, &error);
! if (found_entry || error)
! break;
! }

! if (!error)
! {
! /* If no matching entry was found, synthesize 'reject' entry. */
! if (!found_entry)
! port->auth_method = uaReject;
return true;
}
! else
! return false;
}


--- 855,950 ----
static bool
check_hba(hbaPort *port)
{
ListCell *line;
! HbaLine *hba;

! foreach(line, parsed_hba_lines)
{
! hba = (HbaLine *) lfirst(line);

! /* Check connection type */
! if (hba->conntype == ctLocal)
! {
! if (!IS_AF_UNIX(port->raddr.addr.ss_family))
! continue;
! }
! else
! {
! if (IS_AF_UNIX(port->raddr.addr.ss_family))
! continue;
!
! /* Check SSL state */
! #ifdef USE_SSL
! if (port->ssl)
! {
! /* Connection is SSL, match both "host" and "hostssl" */
! if (hba->conntype == ctHostNoSSL)
! continue;
! }
! else
! {
! /* Connection is not SSL, match both "host" and "hostnossl" */
! if (hba->conntype == ctHostSSL)
! continue;
! }
! #else
! /* No SSL support, so reject "hostssl" lines */
! if (hba->conntype == ctHostSSL)
! continue;
! #endif
!
! /* Check IP address */
! if (port->raddr.addr.ss_family == hba->addr.ss_family)
! {
! if (!pg_range_sockaddr(&port->raddr.addr, &hba->addr, &hba->mask))
! continue;
! }
! #ifdef HAVE_IPV6
! else if (hba->addr.ss_family == AF_INET &&
! port->raddr.addr.ss_family == AF_INET6)
! {
! /*
! * Wrong address family. We allow only one case: if the file has
! * IPv4 and the port is IPv6, promote the file address to IPv6 and
! * try to match that way.
! */
! struct sockaddr_storage addrcopy, maskcopy;
! memcpy(&addrcopy, &hba->addr, sizeof(addrcopy));
! memcpy(&maskcopy, &hba->mask, sizeof(maskcopy));
! pg_promote_v4_to_v6_addr(&addrcopy);
! pg_promote_v4_to_v6_mask(&maskcopy);
!
! if (!pg_range_sockaddr(&port->raddr.addr, &addrcopy, &maskcopy))
! continue;
! }
! #endif /* HAVE_IPV6 */
! else
! /* Wrong address family, no IPV6 */
! continue;
! } /* != ctLocal */
!
! /* Check database and role */
! if (!check_db(port->database_name, port->user_name, hba->database))
! continue;
!
! if (!check_role(port->user_name, hba->role))
! continue;
!
! /* Found a record that matched! */
! port->hba = hba;
return true;
}
!
! /* If no matching entry was found, synthesize 'reject' entry. */
! hba = palloc0(sizeof(HbaLine));
! hba->auth_method = uaReject;
! port->hba = hba;
! return true;
!
! /* XXX:
! * Return false only happens if we have a parsing error, which we can
! * no longer have (parsing now in postmaster). Consider changing API.
! */
}


***************
*** 967,983 ****
}
}


/*
! * Read the config file and create a List of Lists of tokens in the file.
*/
! void
load_hba(void)
{
FILE *file;
!
! if (hba_lines || hba_line_nums)
! free_lines(&hba_lines, &hba_line_nums);

file = AllocateFile(HbaFileName, "r");
/* Failure is fatal since with no HBA entries we can do nothing... */
--- 999,1050 ----
}
}

+ /*
+ * Free the contents of a hba record
+ */
+ static void
+ free_hba_record(HbaLine *record)
+ {
+ if (record->database)
+ pfree(record->database);
+ if (record->role)
+ pfree(record->role);
+ if (record->auth_arg)
+ pfree(record->auth_arg);
+ }

/*
! * Free all records on the parsed HBA list
*/
! static void
! clean_hba_list(List *lines)
! {
! ListCell *line;
!
! foreach(line, lines)
! {
! HbaLine *parsed = (HbaLine *)lfirst(line);
! if (parsed)
! free_hba_record(parsed);
! }
! list_free(lines);
! }
!
! /*
! * Read the config file and create a List of HbaLine records for the contents.
! *
! * The configuration is read into a temporary list, and if any parse error occurs
! * the old list is kept in place and false is returned. Only if the whole file
! * parses Ok is the list replaced, and the function returns true.
! */
! bool
load_hba(void)
{
FILE *file;
! List *hba_lines = NIL;
! List *hba_line_nums = NIL;
! ListCell *line, *line_num;
! List *new_parsed_lines = NIL;

file = AllocateFile(HbaFileName, "r");
/* Failure is fatal since with no HBA entries we can do nothing... */
***************
*** 989,994 ****
--- 1056,1090 ----

tokenize_file(HbaFileName, file, &hba_lines, &hba_line_nums);
FreeFile(file);
+
+ /* Now parse all the lines */
+ forboth(line, hba_lines, line_num, hba_line_nums)
+ {
+ HbaLine *newline;
+
+ newline = palloc0(sizeof(HbaLine));
+
+ if (!parse_hba_line(lfirst(line), lfirst_int(line_num), newline))
+ {
+ /* Parse error in the file, so bail out */
+ free_hba_record(newline);
+ pfree(newline);
+ clean_hba_list(new_parsed_lines);
+ /* Error has already been reported in the parsing function */
+ return false;
+ }
+
+ new_parsed_lines = lappend(new_parsed_lines, newline);
+ }
+
+ /* Loaded new file successfully, replace the one we use */
+ clean_hba_list(parsed_hba_lines);
+ parsed_hba_lines = new_parsed_lines;
+
+ /* Free the temporary lists */
+ free_lines(&hba_lines, &hba_line_nums);
+
+ return true;
}

/*
***************
*** 1100,1106 ****
* See if the user with ident username "ident_user" is allowed to act
* as Postgres user "pgrole" according to usermap "usermap_name".
*
! * Special case: For usermap "samerole", don't look in the usermap
* file. That's an implied map where "pgrole" must be identical to
* "ident_user" in order to be authorized.
*
--- 1196,1203 ----
* See if the user with ident username "ident_user" is allowed to act
* as Postgres user "pgrole" according to usermap "usermap_name".
*
! * Special case: Usermap NULL, equivalent to what was previously called
! * "sameuser" or "samerole", don't look in the usermap
* file. That's an implied map where "pgrole" must be identical to
* "ident_user" in order to be authorized.
*
***************
*** 1116,1129 ****

if (usermap_name == NULL || usermap_name[0] == '\0')
{
- ereport(LOG,
- (errcode(ERRCODE_CONFIG_FILE_ERROR),
- errmsg("cannot use Ident authentication without usermap field")));
- found_entry = false;
- }
- else if (strcmp(usermap_name, "sameuser\n") == 0 ||
- strcmp(usermap_name, "samerole\n") == 0)
- {
if (strcmp(pg_role, ident_user) == 0)
found_entry = true;
else
--- 1213,1218 ----
Index: src/backend/postmaster/postmaster.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.561
diff -c -r1.561 postmaster.c
*** src/backend/postmaster/postmaster.c 26 Jun 2008 02:47:19 -0000 1.561
--- src/backend/postmaster/postmaster.c 16 Aug 2008 15:44:20 -0000
***************
*** 888,894 ****
/*
* Load configuration files for client authentication.
*/
! load_hba();
load_ident();

/*
--- 888,902 ----
/*
* Load configuration files for client authentication.
*/
! if (!load_hba())
! {
! /*
! * It makes no sense continue if we fail to load the HBA file, since
! * there is no way to connect to the database in this case.
! */
! ereport(FATAL,
! (errmsg("could not load pg_hba.conf")));
! }
load_ident();

/*
***************
*** 1926,1932 ****
/* PgStatPID does not currently need SIGHUP */

/* Reload authentication config files too */
! load_hba();
load_ident();

#ifdef EXEC_BACKEND
--- 1934,1943 ----
/* PgStatPID does not currently need SIGHUP */

/* Reload authentication config files too */
! if (!load_hba())
! ereport(WARNING,
! (errmsg("pg_hba.conf not reloaded")));
!
load_ident();

#ifdef EXEC_BACKEND
***************
*** 3080,3086 ****
ALLOCSET_DEFAULT_MAXSIZE);
MemoryContextSwitchTo(PostmasterContext);

! load_hba();
load_ident();
load_role();
#endif
--- 3091,3105 ----
ALLOCSET_DEFAULT_MAXSIZE);
MemoryContextSwitchTo(PostmasterContext);

! if (!load_hba())
! {
! /*
! * It makes no sense continue if we fail to load the HBA file, since
! * there is no way to connect to the database in this case.
! */
! ereport(FATAL,
! (errmsg("could not load pg_hba.conf")));
! }
load_ident();
load_role();
#endif
Index: src/include/libpq/hba.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/libpq/hba.h,v
retrieving revision 1.48
diff -c -r1.48 hba.h
*** src/include/libpq/hba.h 1 Aug 2008 09:09:48 -0000 1.48
--- src/include/libpq/hba.h 16 Aug 2008 15:44:20 -0000
***************
*** 33,42 ****
#endif
} UserAuth;

typedef struct Port hbaPort;

extern List **get_role_line(const char *role);
! extern void load_hba(void);
extern void load_ident(void);
extern void load_role(void);
extern int hba_getauthmethod(hbaPort *port);
--- 33,63 ----
#endif
} UserAuth;

+ typedef enum ConnType
+ {
+ ctLocal,
+ ctHost,
+ ctHostSSL,
+ ctHostNoSSL
+ } ConnType;
+
+ typedef struct
+ {
+ int linenumber;
+ ConnType conntype;
+ char *database;
+ char *role;
+ struct sockaddr_storage addr;
+ struct sockaddr_storage mask;
+ UserAuth auth_method;
+ char *usermap;
+ char *auth_arg;
+ } HbaLine;
+
typedef struct Port hbaPort;

extern List **get_role_line(const char *role);
! extern bool load_hba(void);
extern void load_ident(void);
extern void load_role(void);
extern int hba_getauthmethod(hbaPort *port);
Index: src/include/libpq/libpq-be.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/libpq/libpq-be.h,v
retrieving revision 1.66
diff -c -r1.66 libpq-be.h
*** src/include/libpq/libpq-be.h 26 Apr 2008 22:47:40 -0000 1.66
--- src/include/libpq/libpq-be.h 16 Aug 2008 15:44:20 -0000
***************
*** 121,128 ****
/*
* Information that needs to be held during the authentication cycle.
*/
! UserAuth auth_method;
! char *auth_arg;
char md5Salt[4]; /* Password salt */
char cryptSalt[2]; /* Password salt */

--- 121,127 ----
/*
* Information that needs to be held during the authentication cycle.
*/
! HbaLine *hba;
char md5Salt[4]; /* Password salt */
char cryptSalt[2]; /* Password salt */

Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> To address Magnus' specific question, right now we store the pg_hba.conf
>>> tokens as strings in the postmaster. I am fine with storing them in a
>>> more native format and throwing errors for values that don't convert.
>>> What would concern me is calling lots of 3rd party libraries from the
>>> postmaster to validate items.
>> If I was unclear about that, that part was never part of what I
>> proposed. I'm only talking aobut parsing the syntax. The only external
>> calls in the code there now is the getaddrinfo calls to convert the IPs,
>> IIRC.
>
> That seems safe to me. The use of strings for the pg_hba.conf content
> was only for convenience; I can see the advantage of using a more
> natural format.

Attached is the patch I have so far. The only "extra" it adds over today
is that it allows the use of "ident" authentication without explicitly
specifying "sameuser" when you want that.

Other than that, it moves code around to do the parsing in the
postmaster and the maching in the backend. This means that now if there
is a syntax error in the file on a reload, we just keep the old file
around still letting people log into the database. If there is a syntax
error on server startup, it's FATAL of course, since we can't run
without any kind of pg_hba.

It also changes a couple of error cases to explicitly state that support
for a certain auth method isn't compiled in, rather than just call it a
syntax error.

Comments?

//Magnus

Re: [pgsql-es-ayuda] Inconsistencias con el catálogo?

2008/8/16 Alvaro Herrera <alvherre@alvh.no-ip.org>:
> Alejandro D. Burne escribió:
>> Probablemente se haya planteado anteriormente el caso. Algunas veces
>> uno modifica estructuras de una vista remota, para ello (cuando
>> cambian los campos que la componen, por ejemplo) necesita eliminarla y
>> volver a crearla. El problema se presenta si esa vista es utilizada en
>> una función, ya que al borrarla no genera ninguna advertencia y luego
>> al ejecutar la función nos devuelve un error sobre un objeto
>> inexistente (adjunto un ejemplo).
>
> Esto fue corregido hasta cierto punto en 8.3. Tu ejemplo funciona:
>
> alvherre=> CREATE TABLE _test AS SELECT 1::SMALLINT;
> SELECT
> alvherre=> CREATE OR REPLACE VIEW _vtest AS SELECT * FROM _test;
> CREATE VIEW
> alvherre=> CREATE FUNCTION _ftest() RETURNS void AS
> alvherre-> $BODY$ BEGIN PERFORM 1 FROM _vtest; RETURN; END $BODY$ LANGUAGE 'plp
> sql' VOLATILE;
> CREATE FUNCTION
> alvherre=> SELECT * FROM _ftest();
> _ftest
> --------
>
> (1 ligne)
>
> alvherre=> DROP VIEW _vtest;
> DROP VIEW
> alvherre=> CREATE VIEW _vtest AS SELECT *, 2 FROM _test;
> CREATE VIEW
> alvherre=> SELECT * FROM _ftest();
> _ftest
> --------
>
> (1 ligne)
>


Ok, vamos a montar un nuevo equipo en el cual instalaremos 8.3; por
qué hablas de "corregido hasta cierto punto"? existe algún problema
pendiente?

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

Re: [pgadmin-hackers] pgScript patch based on pgScript-1.0-beta-3

2008/8/14 Dave Page <dpage@pgadmin.org>:
> On Thu, Aug 14, 2008 at 4:34 PM, Magnus Hagander <magnus@hagander.net> wrote:
>>> Does that sound about right?
>>
>> We dumped the static library part, because that library would depend on
>> pgadmin itself, and we'd either get duplicate symbols or a circular
>> reference.
>> (pgScript requires a few classes from pgAdmin to work)
>>
>> So we're back to linking directly with pgadmin.
>
> Oh, OK - well I'm fine with that.

Hi,

I uploaded my last patch. This patch includes:
* pgScript fully integrated with pgAdmin code
(pgadmin/include/pgscript and pgadmin/pgscript)
* pgScript CLI, unit test suite, integration test suite and
documentation in xtra/pgscript
* Help page of the query tool updated and with the pgScript
scripting language reference
* Two pictures for the query tool help page
* An option to ./configure (--disable-pgscript) to disable pgScript
in pgAdmin (this does not work in VC++ of course)
The patch: http://pgscript.projects.postgresql.org/pgadmin/r7403-dif-pgs1.0b4.zip

Best regards,
Mickael

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

Re: [pgsql-es-ayuda] funcion que desde postgres se conecte a bd de informix

andrea lisseth fuentes meneses escribió:
>
> Hola:
>
> Quisiera saber si es posible desde postgres realizar una conexion a una base de datos de informix , para consultar información de la base de datos de informix e insertarla en unas tablas de postgres.. Alguien que me podria dar una idea de como hacerlo.?

Se supone que debería poderse usando DBI-Link. Antes de probarlo
asegúrate de tener un programa en Perl que sea capaz de conectarse a tu
BD informix.

--
Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [PERFORM] file system and raid performance

Greg Smith wrote:
> On Fri, 15 Aug 2008, Bruce Momjian wrote:
>> 'data=writeback' is the recommended mount method for that file
>> system, though I see that is not mentioned in our official
>> documentation.
> While writeback has good performance characteristics, I don't know
> that I'd go so far as to support making that an official
> recommendation. The integrity guarantees of that journaling mode are
> pretty weak. Sure the database itself should be fine; it's got the
> WAL as a backup if the filesytem loses some recently written bits.
> But I'd hate to see somebody switch to that mount option on this
> project's recommendation only to find some other files got corrupted
> on a power loss because of writeback's limited journalling. ext3 has
> plenty of problem already without picking its least safe mode, and
> recommending writeback would need a carefully written warning to that
> effect.

To contrast - not recommending it means that most people unaware will be
running with a less effective mode, and they will base their performance
measurements on this less effective mode.

Perhaps the documentation should only state that "With ext3,
data=writeback is the recommended mode for PostgreSQL. PostgreSQL
performs its own journalling of data and does not require the additional
guarantees provided by the more conservative ext3 modes. However, if the
file system is used for any purpose other than PostregSQL database
storage, the data integrity requirements of these other purposes must be
considered on their own."

Personally, I use data=writeback for most purposes, but use data=journal
for /mail and /home. In these cases, I find even the default ext3 mode
to be fewer guarantees than I am comfortable with. :-)

Cheers,
mark

--
Mark Mielke <mark@mielke.cc>


--
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] Inconsistencias con el catálogo?

Alejandro D. Burne escribió:
> Probablemente se haya planteado anteriormente el caso. Algunas veces
> uno modifica estructuras de una vista remota, para ello (cuando
> cambian los campos que la componen, por ejemplo) necesita eliminarla y
> volver a crearla. El problema se presenta si esa vista es utilizada en
> una función, ya que al borrarla no genera ninguna advertencia y luego
> al ejecutar la función nos devuelve un error sobre un objeto
> inexistente (adjunto un ejemplo).

Esto fue corregido hasta cierto punto en 8.3. Tu ejemplo funciona:

alvherre=> CREATE TABLE _test AS SELECT 1::SMALLINT;
SELECT
alvherre=> CREATE OR REPLACE VIEW _vtest AS SELECT * FROM _test;
CREATE VIEW
alvherre=> CREATE FUNCTION _ftest() RETURNS void AS
alvherre-> $BODY$ BEGIN PERFORM 1 FROM _vtest; RETURN; END $BODY$ LANGUAGE 'plp
sql' VOLATILE;
CREATE FUNCTION
alvherre=> SELECT * FROM _ftest();
_ftest
--------

(1 ligne)

alvherre=> DROP VIEW _vtest;
DROP VIEW
alvherre=> CREATE VIEW _vtest AS SELECT *, 2 FROM _test;
CREATE VIEW
alvherre=> SELECT * FROM _ftest();
_ftest
--------

(1 ligne)

--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"Puedes elegir el color de tu auto -- siempre y cuando sea negro."
(Henry Ford)
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html

Re: [ADMIN] pgCluster and PostgreSQL

On Fri, 2008-08-15 at 16:55 -0300, DANIEL CRISTIAN CRUZ wrote:
> I was looking at PostgreSQL docs, and didn't found any reference about
> a merge of PostgreSQL. A long time ago I saw somenthig about this.

No, PgCluster will never merge with PostgreSQL Core. PgCluster is not
mature enough to be added to the core, and also PG Core team does not
want to add such solutions to core (which I like very much).

-HTH

--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Re: [ADMIN] pgCluster and PostgreSQL

On Fri, 2008-08-15 at 23:59 +0200, Mathias Stjernström wrote:
> But http://pgcluster.projects.postgresql.org/ have not been updated
> since 2005 ;)

http://www.pgcluster.org

Regards,
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Re: [pgadmin-hackers] pgScript patch based on pgScript-1.0-beta-3

Hi Erikjan,

Here a few answers to your questions.

2008/8/14 Erikjan Rijkers <er@xs4all.nl>:
> 1) It would be nice if pgScript would only execute a select-block, like the
> normal pgAdmin querytool does.

Do you mean: redirecting a pgScript script to the regular query tool
if both the pgScript button is pressed and the edit window contains
only a select statement?
If this is case, I do not think it should be a good idea because
pgScript has its own behavior and it should not change whether there
is only one select statement or more in the edit window. Or maybe I
misunderstood your observation.

> 2) The example script from the url above says:
>
> IF (SELECT 1 FROM table) -- Then table exists
>
> which is only true if the table has rows, which of course initially it hasn't.
> This totally confounds the pgScript newbie ;-) Maybe it can be changed to:
>
> IF (SELECT count(*) FROM table) -- Then table exists
>
> Now it will NOT fail when table exist, but is empty.
>
> This will make the snippet executable with pressing repeated F6.

Ok, it was a mistake in the documentation. I just tested this kind of
script and if the query returns nothing or it fails then the result is
considered false.
You're right, with a count(*) it returns something (0 if no rows) and
this is true.

> 3) When the BEGIN - END block fails, pgScript executes the ELSE block. This
> seems questionable behaviour, no? It can be seen with that same
> above-mentioned script. (in the original 'IF (SELECT 1 FROM table)' form )

I do not understand this observation. Could you be more precise please?

I just bring some clarity on my side:
1) BEGIN and END are like { and } in C++. They enclose blocks but they
have nothing to do with transactions
(http://pgscript.projects.postgresql.org/SCRIPT.html#id4731518).
You must use BEGIN TRANSACTION and END TRANSACTION for transactions
otherwise it conflicts with pgScript.
2) When a query fails (syntax error, ...) it does not interrupt the
script. In this case you have a WARNING with the error message. In the
case the query is fine you have a NOTICE.

This script outputs 'table exists' if the table t1 actually exists and
then exits because of an assertion failure, but it does not execute
the else block.

if (select count(*) from t1)
begin
print 'table exists';
assert 0;
end
else
begin
print 'table does not exist';
end

In the "select count(*) from t1" in the above script is replaced with
a erroneous query "select count(*) fm t1" then you have a WARNING
because of the incorrect query and then it goes to the else block.
This is not really correct but except aborting the script I do not see
how I can do otherwise. Was this your observation?

Many thanks for your feedback,
Mickael

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