Modified Files:
--------------
pgrpm:
ChangeLog (r1.12 -> r1.13)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgrpm/pgrpm/ChangeLog.diff?r1=1.12&r2=1.13)
Makefile (r1.32 -> r1.33)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgrpm/pgrpm/Makefile.diff?r1=1.32&r2=1.33)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Modified Files:
--------------
pgrpm:
pgheader.c (r1.30 -> r1.31)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgrpm/pgrpm/pgheader.c.diff?r1=1.30&r2=1.31)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Wierd, at least in glibc and ICU it can't happen but perhaps there are
other implementations where it can...
> Collation cannot be defined on any character. There is not any relation
> between
> Latin and Chines characters. Collation has sense when you are able to
> specify < = > operators.
There is no standardised relation. However, if your collation library
decides to define all chinese characters after all latin characters,
they will have defined a collation that will work for all strings with
any characters... Which is basically the approach glibc/ICU takes.
I think the standard is kind of pathetic to say that strcoll can set
errno but have no value to indicate error. I wonder how many platforms
actually use that "feature".
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.
This is mainly for the archives should someone else like to beat SCO into partial submission....
Regression testing does not work for reasons I don't know when attempting them from the makefiles.
ie make check.
BUT screen scrapping the executed commands and/or suggestions does work.
Here is what worked ( scrapped from bash history, hope I go it right ). Substitute you own installation path.
cd src/test/regress
rm -r /upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/data
/upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb -D /upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/data -L /upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/install/usr/local/pgsql/share --noclean --no-locale
/upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/postgres -D /upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/data
In another shell...
cd src/test/regress
./pg_regress --psqldir=/upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/install//usr/local/pgsql/bin --schedule=./serial_schedule --srcdir=/upgrades/postgres/postgresql-8.3.3/src/test/regress --multibyte=SQL_ASCII --load-language=plpgsql --host=localhost
All tests passed, save for those that use "Infinity" and "NaN" and variants on that theme. I can post regression.diffs
should anyone want them.
Regression testing is however the end of the story, getting it compiled was the main effort.
Summarised here:
Get GNU gawk and tar and substitute the SCO distributed versions.
Do not use the SCO Open server development environment ( export CC=cc; ./configure; etc etc ) as 64 bit is not supported an even more regression tests fail.
The Unixware and OpenServer Development Kit compiles nicely, but promptly core dumps with unsupported system calls in the compatibility module or some such.
Attempting to use the Skunkware gcc (2.95.3) fails in ./configure ( export CC=gcc ).
With the help of http://archives.postgresql.org/pgsql-bugs/2001-06/msg00141.php
and http://archives.postgresql.org/pgsql-ports/2008-06/msg00001.php
The correct options can be given to gcc.
src/makefiles/Makefile.sco is the wrong place, see link above,
/src/template/sco is the right place and I made it
#CC="$CC -b elf"
CC="$CC -melf"
The make worked which lead to the regression testing, see above.
Note UNIX sockets seem broken for get/setsockopt() so always connect over TCP/IP. ie --host=localhost seems to work around it.
Hope this helps someone else.
Now to the actuall upgrade.....
Allan
The material contained in this email may be confidential, privileged or copyrighted. If you are not the intended recipient, use, disclosure or copying of this information is prohibited. If you have received this document in error, please advise the sender and delete the document. Neither OneSteel nor the sender accept responsibility for any viruses contained in this email or any attachments.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> bison 1.875 is available here:
> http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=22822
To the best of my knowledge, any bison version >= 1.875 works
fine; you need not insist on finding exactly those two releases.
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
Read
http://www.postgresql.org/docs/8.3/static/xindex.html
particularly the discussion of cross-type index operators.
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
> For example, PostgreSQL currently uses the pg_catalog schema to store
> system catalogs / relations / functions / etc. Has thought gone into
> extending the scope to allow contrib modules to create their own
> catalogs (ie. a PostGIS catalog, cube, tsearch2, etc.)?
A superuser can create whatever he wants in pg_catalog. Whether this
is a good idea or will behave smoothly is a topic that has not been
thought about, to my knowledge.
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
> The linker hardcodes library paths into exes and libs. We examine
> these paths at install time using otool and rewrite them from the
> staging paths on the build machine to whatever directory the user
> chose to install to using install_name_tool(1).
> The other option would be to rewrite the paths to be relative at build
> time I guess.
Relative paths sound like the best solution to me, assuming they work.
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
I find this a bit dubious. If the inner rel is small enough to fit in
memory then it buys nothing. If not, then you win only to the extent
that a pretty large fraction of the inner rel fits in memory. In any
case you are relying on the assumption that backwards scan is just as
efficient as forward scan, which seems to me to be a pretty large
assumption --- we expect forward seqscans to get a performance boost
from kernel readahead, but I'd be surprised if the kernel recognized
what was happening in a backwards scan.
Note also that backwards scan doesn't work at all in some plan
node types (cf ExecSupportsBackwardScan). You'd need to check
what the inner input node was before trying this.
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
Thanks for the report. Here is the new patches from Yoshiyuki. It
appeared that addRangeTableEntryForRecursive() needs to do deep copy
for the subquery and ref in the RangeTblEntry to avoid double free
bug (remember that your example is a self join case).
Also I added your query to the regression test case with minor
modifications.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
And one for Oracle as well. I've seen a few people show up wondering
how postgresql handles running out of rollback space... ahem.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
You know, I bet as many of us came to PostgreSQL from a MySQL background
as from Oracle. It might be good to have a section in the manual for how
to transition from using the "tricks" in MySQL to a strict environment
like Postgres.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> Is the otool program on your system anywhere? Afaik, it should be on
> any Mac, but maybe it's part of xcode (i hope not- can anyone
> confirm?)
I have a few installs here.
otool is included inside /Developer/usr/bin
my working 10.4 that the dev tools is installed on also includes otool
at /usr/bin
A minimal 10.3 install has otool at /usr/bin
A clean 10.5 install does not have otool
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
* Simon Riggs (simon@2ndquadrant.com) wrote:
> ...and with command line help also.
The documentation and whatnot looks good to me now. There are a couple
of other issues I found while looking through and testing the patch
though-
Index: src/bin/pg_dump/pg_dump.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.497
diff -c -r1.497 pg_dump.c
*** src/bin/pg_dump/pg_dump.c 20 Jul 2008 18:43:30 -0000 1.497
--- src/bin/pg_dump/pg_dump.c 23 Jul 2008 17:04:24 -0000
***************
*** 225,232 ****
RestoreOptions *ropt;
static int disable_triggers = 0;
! static int outputNoTablespaces = 0;
static int use_setsessauth = 0;
static struct option long_options[] = {
{"data-only", no_argument, NULL, 'a'},
--- 229,238 ----
RestoreOptions *ropt;
static int disable_triggers = 0;
! static int outputNoTablespaces = 0;
static int use_setsessauth = 0;
+ static int use_schemaBeforeData;
+ static int use_schemaAfterData;
static struct option long_options[] = {
{"data-only", no_argument, NULL, 'a'},
***************
This hunk appears to have a bit of gratuitous whitespace change, not a
big deal tho.
***************
*** 464,474 ****
[...]
+ if (dataOnly)
+ dumpObjFlags = REQ_DATA;
+
+ if (use_schemaBeforeData == 1)
+ dumpObjFlags = REQ_SCHEMA_BEFORE_DATA;
+
+ if (use_schemaAfterData == 1)
+ dumpObjFlags = REQ_SCHEMA_AFTER_DATA;
+
+ if (schemaOnly)
+ dumpObjFlags = (REQ_SCHEMA_BEFORE_DATA | REQ_SCHEMA_AFTER_DATA);
***************
It wouldn't kill to be consistant between testing for '== 1' and just
checking for non-zero. Again, not really a big deal, and I wouldn't
mention these if there weren't other issues.
***************
*** 646,652 ****
* Dumping blobs is now default unless we saw an inclusion switch or -s
* ... but even if we did see one of these, -b turns it back on.
*/
! if (include_everything && !schemaOnly)
outputBlobs = true;
/*
--- 689,695 ----
* Dumping blobs is now default unless we saw an inclusion switch or -s
* ... but even if we did see one of these, -b turns it back on.
*/
! if (include_everything && WANT_PRE_SCHEMA(dumpObjFlags))
outputBlobs = true;
/*
***************
Shouldn't this change be to "WANT_DATA(dumpObjFlags)"? That's what most
of the '!schemaOnly' get translated to. Otherwise I think you would be
getting blobs when you've asked for just schema-before-data, which
doesn't seem like it'd make much sense.
***************
*** 712,718 ****
dumpStdStrings(g_fout);
/* The database item is always next, unless we don't want it at all */
! if (include_everything && !dataOnly)
dumpDatabase(g_fout);
/* Now the rearrangeable objects. */
--- 755,761 ----
dumpStdStrings(g_fout);
/* The database item is always next, unless we don't want it at all */
! if (include_everything && WANT_DATA(dumpObjFlags))
dumpDatabase(g_fout);
/* Now the rearrangeable objects. */
***************
Shouldn't this be 'WANT_PRE_SCHEMA(dumpObjFlags)'?
***************
*** 3414,3420 ****
continue;
/* Ignore indexes of tables not to be dumped */
! if (!tbinfo->dobj.dump)
continue;
if (g_verbose)
--- 3459,3465 ----
continue;
/* Ignore indexes of tables not to be dumped */
! if (!tbinfo->dobj.dump || !WANT_POST_SCHEMA(dumpObjFlags))
continue;
if (g_verbose)
***************
I didn't test this, but it strikes me as an unnecessary addition? If
anything, wouldn't this check make more sense being done right after
dropping into getIndexes()? No sense going through the loop just for
fun.. Technically, it's a behavioral change for --data-only since it
used to gather index information anyway, but it's a good optimization if
done in the right place.
Also around here, there doesn't appear to be any checking in
dumpEnumType(), which strikes me as odd. Wouldn't that deserve a
if (!WANT_PRE_SCHEMA(dumpObjFlags))
return;
check? If not even some kind of equivilant ->dobj.dump check..
***************
*** 9803,9809 ****
tbinfo->dobj.catId, 0, tbinfo->dobj.dumpId);
}
! if (!schemaOnly)
{
resetPQExpBuffer(query);
appendPQExpBuffer(query, "SELECT pg_catalog.setval(");
--- 9848,9854 ----
tbinfo->dobj.catId, 0, tbinfo->dobj.dumpId);
}
! if (WANT_PRE_SCHEMA(dumpObjFlags))
{
resetPQExpBuffer(query);
appendPQExpBuffer(query, "SELECT pg_catalog.setval(");
***************
This is a mistaken logic invert, which results in setval's not being
dumped at all when pulling out each piece seperately. It should be:
if (WANT_DATA(dumpObjFlags))
so that setval's are correctly included on the --data-only piece. As
--data-only previously existed, this would be a regression too.
Index: src/bin/pg_dump/pg_restore.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/bin/pg_dump/pg_restore.c,v
retrieving revision 1.88
diff -c -r1.88 pg_restore.c
*** src/bin/pg_dump/pg_restore.c 13 Apr 2008 03:49:22 -0000 1.88
--- src/bin/pg_dump/pg_restore.c 23 Jul 2008 17:06:59 -0000
+ if (dataOnly)
+ dumpObjFlags = REQ_DATA;
+
+ if (use_schemaBeforeData == 1)
+ dumpObjFlags = REQ_SCHEMA_BEFORE_DATA;
+
+ if (use_schemaAfterData == 1)
+ dumpObjFlags = REQ_SCHEMA_AFTER_DATA;
+
+ if (schemaOnly)
+ dumpObjFlags = (REQ_SCHEMA_BEFORE_DATA | REQ_SCHEMA_AFTER_DATA);
+
***************
Ditto previous comment on this, but in pg_restore.c.
***************
*** 405,410 ****
--- 455,462 ----
" do not restore data of tables that could not be\n"
" created\n"));
printf(_(" --no-tablespaces do not dump tablespace assignments\n"));
+ printf(_(" --schema-before-data dump only the part of schema before table data\n"));
+ printf(_(" --schema-after-data dump only the part of schema after table data\n"));
printf(_(" --use-set-session-authorization\n"
" use SESSION AUTHORIZATION commands instead of\n"
" OWNER TO commands\n"));
***************
Forgot to mention this on pg_dump.c, but in both pg_dump and pg_restore,
and I hate to be the bearer of bad news, but your command-line
documentation doesn't line up properly in the output. You shouldn't be
using tabs there but instead should use spaces as the other help text
does, so everything lines up nicely.
Thanks,
Stephen
If you should have put id 5 instead of id 2 as a foreign key, how is the
database going to know the difference? Both are valid id's and valid
data for an "int" type field.
How can I
> even include something *outside* a transaction *inside* it- shouldn't
> everything between "begin" and "end" be subject to auto rollback no
> matter what?
Most things in postgres are transaction safe, some aren't like "cluster"
or "vacuum full". I couldn't find a list of things that won't work in a
transaction but it's a pretty short list. Even table changes (alter
table, create index etc) are transaction safe.
Maybe I misunderstand the question.
> Also what is the best way to check if transaction is 'read write'
> after doing 'pg_query("begin transaction read write;", $connection);'.
> pg_transaction_status() doesn't quite do it (read write=?=2).
That's going to report if you're inside a transaction or not, it's not
going to report what transaction level you are in. I don't think there's
a way to show that.
--
Postgresql & php tutorials
http://www.designmagick.com/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Nobody ever said this was supported AFAIK. VC++ Express 2005 is the
supported compiler so far.
> - ok with VS Express 2005 but integration issues with Platform SDK
Right.
> - issues locating the 14 required software packages:
> - no luck getting Bison 1.875 or 2.2 Windows binaries
bison 1.875 is available here:
http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=22822
> - linkage errors with the latest ActivePerl/TCL libraries
Ugh.
What would be helpful would be a build log. something like:
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=mastodon&dt=2008-07-24%20010001&stg=make
or an extract from it.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo comun"
*-------------------------------------------------------*
> Date: Tue, 22 Jul 2008 00:32:39 -0500
> From: gwolf@gwolf.org
> To: alvherre@alvh.no-ip.org
> CC: rodpin@gmail.com; pgsql-es-ayuda@postgresql.org
> Subject: Re: [pgsql-es-ayuda] como lograr campo consecutivo sin fallar ?
>
> Alvaro Herrera dijo [Thu, Jul 17, 2008 at 01:33:41PM -0400]:
>> Claro, pero para hacer una asignación numérica que "no falle" no puedes
>> usar una secuencia. Tienes que bloquear la tabla y hacer la inserción
>> del siguiente número disponible. Esto obviamente tiene menor
>> rendimiento (solo puede haber un proceso insertando a la vez), pero te
>> aseguras que no habrá agujeros en la numeración.
>>
>> Dado que la generación de facturas no es una cosa terriblemente
>> frecuente, el menor rendimiento no debería ser un problema. Cada
>> transacción debería tomar menos de un segundo de todas maneras. Un
>> usuario que tiene que esperar un segundo más, no se da ni cuenta de la
>> diferencia.
>
> Pero incluso siendo este el caso, yo no usaría al número de factura
> como la llave primaria. Generaría en todo caso algo como:
>
> CREATE TABLE factura (
> id SERIAL PRIMARY KEY,
> factura integer NOT NULL DEFAULT siguiente_factura(),
Esto se puede ?
Puedo poner como DEFAULT una funcion que he hecho>?
Wao!!
Eso si que no lo sabiaQ!!!
> otro_campo blah blah
> );
>
> Claro, poniendo la lógica en cuestión bajo siguiente_factura(), y
> creándole un bonito índice para el rendimiento. Sí, sé que el número
> de factura no _debe_ cambiar, pero... Bueno, todos los atributos que
> un humano pueda tocar son malas opciones para una llave primaria. Y no
> sé cómo sea en sus países, pero en México tú no puedes imprimir el
> número de factura - tiene que venir pre-impreso por un impresor
> autorizado. Eso sólo significa que el número de factura se tiene que
> capturar una vez teniendo el papelito impreso (o listo en la
> impresora).
>
> Saludos,
>
> --
> Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
> --
> TIP 7: no olvides aumentar la configuración del "free space map"
_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán
* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo comun"
*-------------------------------------------------------*
> Date: Mon, 21 Jul 2008 00:14:26 -0500
> From: jcasanov@systemguards.com.ec
> To: listas_quijada@hotmail.com
> Subject: Re: [pgsql-es-ayuda] Conexiones simultaneas
> CC: alvherre@alvh.no-ip.org; pgsql-es-ayuda@postgresql.org
>
> 2008/7/18 Edwin Quijada :
>>
>> estoy usando Debian.
>> Ayer mi sistema se cayo porque llego al limite maximo de conexiones,100 y tuve que de emergencia subirlo a 1000.
>> Aun no he podido bajarlo porque el sistema esta en produccion y necesito hacer restart.
>> Me preocupa que PostgreSQL reserve algo al declarar este limite tan alto de conexiones simulataneas.?
>>
>
> y por que no usas un pool de conexiones?
>
La verdad aun no se como se usan PgPool o PgBouncer tendre que darme una leidita mas fuerte.
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Guayaquil - Ecuador
> Cel. (593) 87171157
> --
> TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán
_________________________________________________________________
Keep your kids safer online with Windows Live Family Safety.
http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_family_safety_072008--
TIP 4: No hagas 'kill -9' a postmaster
> When I select the datas with this instruction
> "select a.x from a,b where a.z = b.z order by 1"
> the program run very well and I can insert, update and delete rows. But,
> when I select any column from table b an error occurs when I try to modify
> the column value from textbox for an example.
> "Binding Collection Error. field not updatable".
Maybe you should try your query from psql, and see if it works fine
there. If it does, then you know the problem is in your data access
driver or application.
At a guess, I'd say you'll be having issues with data type support in
the data access driver. You are using a prehistoric programming
language, which won't be helping.
You should post your query (if it's generated by your app at runtime,
get it by enabling query logging in the database and fishing it out of
the PostgreSQL log) and the schema definition of the problem table as
obtained with psql's \d command.
--
Craig Ringer
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
> The linker hardcodes library paths into exes and libs. We examine these
> paths at install time using otool and rewrite them from the staging
> paths on the build machine to whatever directory the user chose to
> install to using install_name_tool(1).
Yep, the mac linker seems to default to absolute rpath linking, which I
personally find *really* frustrating.
> The other option would be to rewrite the paths to be relative at build
> time I guess.
That's the approach most Mac apps take, and is supported by the @
relative path syntax in install_name_tool.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
trying to build postgres on Windows, I ran into a number of
problems not covered by the FAQs or the PostgreSQL 8.3.3
documentation:
http://www.postgresql.org/docs/8.3/interactive/install-win32-full.html
In short, it's not been an easy experience so far:
- build errors with latest Visual Studio Express C++ 2008
- ok with VS Express 2005 but integration issues with Platform SDK
- issues locating the 14 required software packages:
- no luck getting Bison 1.875 or 2.2 Windows binaries
- linkage errors with the latest ActivePerl/TCL libraries
- locating a OSSP-UUID binary package for Windows
(.dll but no uuid.h with Hiroshi Saito's binary package?)
Below are more details / questions / suggestions with the goal to
help for a better build experience on Windows.
Any hints or comments welcome!
Regards,
Martin
1) Build errors with Visual Studio Express C++ 2008
For building with Visual Studio Express 2005, the Microsoft
Platform SDK needs to be downloaded, installed, and integrated
into the INCLUDE/LIB/PATHs.
However, since Visual Studio Express 2008 already comes with
the integrated SDK, I tried this one first. Ran into a number
of VCBuild errors:
vcbuild.exe : error VCBLD0010: Project 'G:\olsen\pg\pgsql\postgres.vcproj' requ
ires upgrade. Use 'vcbuild /upgrade' or 'devenv /upgrade' to upgrade the projec
t.
Couldn't get past these errors by executing "vcbuild /upgrade"
on the generated .vcproj files. The VS Release Notes and
other sites describe this issue a bit but to not much help.
==> Anyone knowing how to build postgres with VC++ 2008?
2) Back to Visual Studio Express C++ 2005 & MS Platform SDK
The postgres documentation wasn't specific but I installed
Microsoft Platform SDK for Windows Server 2003 R2
http://www.microsoft.com/downloads/details.aspx?FamilyID=0baf2b35-c656-4969-ace8-e4c0c0716adb&DisplayLang=en
for I guessed this the basis for the Postgres documentation.
There's a newer version, though, now called Windows SDK:
Windows SDK for Windows Server 2008 and .NET Framework 3.5
http://www.microsoft.com/downloads/details.aspx?FamilyID=e6e1c3df-a74f-4207-8586-711ebe331cdc&DisplayLang=en
==> Anyone tried building PG with latest Windows SDK (2008)?
3) Issues adding Platform SDK paths to VC++ 2005
The README in pgsql/src/tools/msvc/ informs about the steps
needed to integrate the Platform SDK with VC++ 2005 by editing
the Include, Library and Path tags in the files
vcprojectengine.dll.express.config
vcprojectengine.dll.config
under the VC++ directory vc\vcpackages.
The README's following assertion is not correct, I think:
"This should work for both GUI and commandline builds, but a
restart may be necessary."
While the Include/Lib/Path changes appear to be in effect for
the GUI they are NOT in the Visual Studio 2005 Command Prompt!
(even after restart)
The following MS pages
http://www.microsoft.com/express/2005/platformsdk/default.aspx
http://www.microsoft.com/express/2005/platformsdk/default.aspx
describe additional steps, notably to also delete the file
vccomponents.dat
located in
%USERPROFILE%\Local Settings\Application Data\Microsoft\VCExpress\8.0
before restarting VC++ Express Edition.
But this didn't change the paths in the VS 2005 Command Prompt
either. So I had to change the user INCLUDE/LIB/PATH
environment manually.
Actually, I'm using the Command Prompt from the MS Platform
SDK's Build Environment selection, not the VS 2005 start menu,
for other important environment settings (target OS, 32/64,
debug/release etc).
==> Does the README's assertion need to be changed/corrected?
4) Issues with locating the 14 required software packages
- ActiveState Perl, ActiveState TCL
Had to click around to find out that I don't want the
"ActivePerl Pro Studio Free Trial" software but the
"ActivePerl". Same with ActiveTcl.
Problem: found out later that PG doesn't build with the
latest ActivePerl/TCL language packs!
- Bison, Flex
The PG documentation states: only Bison 1.875 or versions
2.2 and later will work.
Problem: The GnuWin32 website only offers Bison 2.1!
- Diff, Gettext
No problems.
- MIT Kerberos
No problems but unsure how to answer some of the
installation questions.
- libxml2, libxslt, iconv
No problems.
- openssl
No problems but unsure how to answer some of the
installation questions.
- ossp-uuid
Downloaded source from http://www.ossp.org/pkg/lib/uuid/.
Problem: from where to get a ossp-uuid Windows binary?
- Python
No problems.
- zlib
No problems.
==> Can't we provide a package for download with all/most of
the libraries/tools needed for building PG on Windows?
5) Configuring pgsql/src/tools/msvc/config.pl, buildenv.pl
A typo in my config.pl had the build aborting with only
The system cannot find the path specified.
and no further clues.
==> More information on misconfigured config.pl would help!
6) Getting a Bison 1.875 or 2.2 Windows binary
Google couldn't find me a Windows binary and I didn't want to
build one myself (using mingw). So, I copied cygwin's 2.2
binary, together with the needed .dlls, into an empty
directory at the end of the PATH.
==> Using cygwin's Bison 2.2 worked!
7) Linkage errors with the latest ActivePerl/TCL libraries
Having installed the latest ActivePerl/TCL language packs
(Perl: 5.10.0.1003, TCL: 8.5.2.0.284846) resulted in linkage
errors against libraries 'tk84.lib' and 'perl85.lib'.
I couldn't determine where those library were hardcoded, so, I
downloaded and installed older versions (Perl: 5.8.8.822, TCL:
8.4.19.0.285137. Worked!
==> Fixing the linkage errors against the latest ActivePerl/TCL
libs or documenting the version requirements would be great!
8) Getting a Windows OSSP-UUID library
Google found me a postgres hackers email thread with this link
http://winpg.jp/~saito/pg_work/OSSP_win32/
to 1.6.2 uuid-ossp.dll mingw-compiled by Hiroshi Saito. Thanks!
Problem: from where to get the also needed uuid.h?
I've seen that Hiroshi Saito has worked on a patch for building the
uuid-ossp package on Windows. I didn't succeed in building
ossp-uuid using wingw on Windows and took the shortcut of using
cygwin to generate the uuid.h.
But that hack didn't work, I'm getting linkage errors:
uuid.lib(uuid_str.obj) : error LNK2019: unresolved external symbol _va_copy referenced in function _uuid_str_vasprintf
.\Release\uuid-ossp\uuid-ossp.dll : fatal error LNK1120: 1 unresolved externals
==> Where can I find a complete ossp-uuid package for Windows?
And this is where I am right now. Any hints/comments welcome!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> It wouldn't be too hard if you don't mind running a custom Postgres
> build; but if you do, then the best answer might be to cannibalize one of
> the existing encoding names and just replace its conversion procedures.
Actually, I'd recommend not doing that. Instead, put in your encoding as
a new encoding, and send a diff of your changes to the Postgres team. I
bet next release it would be a supported encoding, and you would be able
to upgrade without any issues...
Daniel T. STaal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice
---------- Forwarded message ----------
From: "Tom Dunstan" <tomdcc@gmail.com>
To: "Dimitri Fontaine" <dfontaine@hi-media.com>
Date: Wed, 23 Jul 2008 19:40:30 -0400
Subject: Re: [HACKERS] PostgreSQL extensions packaging
Hi!
On Wed, Jul 23, 2008 at 5:08 PM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> I promised to have an in-depth look at the archives before to spend time on
> my ideas for $subject, but failed to do so.
I guess that means you missed both the original discussion at
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php and
my initial patch in that direction and subsequent discussion at
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php then
:(.
There were two core components to my idea of modules/packages:
- Separation of installation at an OS level (RPM/yum, deb/dpkg, MSI
installer etc) and installation into a database. The intention was a)
to standardize package installation generally so that users didn't
have to read n different sets of installation instructions for n
different packages, and b) so that a db owner could install into their
own database any module that had been installed on the system, even if
that might include e.g. C functions that they otherwise would not be
able to install without being a superuser.
- Have dependency tracking so that pg_dump could emit e.g. "LOAD
MODULE foo;" rather than all the different instructions to recreate
the module.
So the proposed installation procedure would be more along the lines of:
yum install postgresql-module-postgis
echo "load module postgis" | psql mydb
My intention was to use whatever native package manager was
appropriate for your distro rather than trying to recreate CPAN,
although some people in the original discussion wanted to go down that
route.
The patch that I provided didn't do any of the dependency stuff yet -
I had been investigating various ways to do it automagically, although
I haven't worked on it for a little while. It may be that the straight
forward explicit declaration that you have here is a better way to do
it.
I didn't have versioning and interdependencies between modules yet,
although it's an obvious extension to the idea.
> A package can also host variables, which visibility are
> package global: any SQL into the package can refer directly to package
> variables.
That was way out of scope for my more modest suggestion - I certainly
wasn't going to change pl/pgsql semantics. For example, how do those
variables behave upon a transaction rollback?
> Now, what would be really good to have would be this pg_pkg command I was
> dreaming about in another -hacker mail:
This turns into recreating CPAN. I like the idea of a "blessed" set of
packages, but would rather not require all postgresql users to have a
full build environment (especially on windows) and have to replace
their native packaging solution. It seems that you agree that
fetching/installing should be separate from loading/installing into
the database. Good. Some posters on the original thread were
suggesting that the fetch/install step should somehow do the database
installation as well, which sounded like a huge can of worms.
I think that we can come up with a package/module format that allows
installation at the OS level without demanding a whole set of download
/ build machinery. If someone then wants to build that and have it
install packages, then fine, but we definitely should not require it
to be able to install stuff.
Look forward to your comments
Cheers
Tom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks!
---------------------------------------------------------------
If everything seems under control, you're not going fast enough
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Thanks for the report. We will look into this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> (gdb) continue
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08192dcd in ExecQual (qual=0xa183824, econtext=0xa183230, resultForNull=0 '\0') at execQual.c:4513
> 4513 expr_value = ExecEvalExpr(clause, econtext, &isNull, NULL);
> (gdb) i s
> #0 0x08192dcd in ExecQual (qual=0xa183824, econtext=0xa183230, resultForNull=0 '\0') at execQual.c:4513
> #1 0x08199b23 in ExecScan (node=0xa1831a4, accessMtd=0x81a6bb0 <RecursivescanNext>) at execScan.c:131
> #2 0x081a6ba9 in ExecRecursiveScan (node=0xa1831a4) at nodeRecursivescan.c:48
> #3 0x08192320 in ExecProcNode (node=0xa1831a4) at execProcnode.c:380
> #4 0x081a6923 in RecursionNext (node=0xa17fe18) at nodeRecursion.c:68
> #5 0x08199a83 in ExecScan (node=0xa17fe18, accessMtd=0x81a6840 <RecursionNext>) at execScan.c:68
> #6 0x081a6839 in ExecRecursion (node=0xa17fe18) at nodeRecursion.c:116
> #7 0x081923e0 in ExecProcNode (node=0xa17fe18) at execProcnode.c:339
> #8 0x081a1c13 in MultiExecHash (node=0xa17fcc4) at nodeHash.c:94
> #9 0x081a28b9 in ExecHashJoin (node=0xa17b654) at nodeHashjoin.c:159
> #10 0x081922d8 in ExecProcNode (node=0xa17b654) at execProcnode.c:395
> #11 0x081901db in standard_ExecutorRun (queryDesc=0xa15c334, direction=ForwardScanDirection, count=0) at execMain.c:1271
> #12 0x08240dc4 in PortalRunSelect (portal=0xa15631c, forward=1 '\001', count=0, dest=0xa1733d8) at pquery.c:937
> #13 0x082420e6 in PortalRun (portal=0xa15631c, count=2147483647, isTopLevel=1 '\001', dest=0xa1733d8, altdest=0xa1733d8,
> completionTag=0xbfcacaea "") at pquery.c:793
> #14 0x0823d0a7 in exec_simple_query (
> query_string=0xa12fc9c "WITH RECURSIVE t(i) AS (VALUES(1::int) UNION ALL SELECT i+1 FROM t WHERE i < 5) SELECT * FROM t AS t1 JOIN t AS t2 USING(i);") at postgres.c:977
> #15 0x0823e84c in PostgresMain (argc=4, argv=0xa0d0dac, username=0xa0d0d7c "shackle") at postgres.c:3559
> #16 0x0820957f in ServerLoop () at postmaster.c:3238
> #17 0x0820a4e0 in PostmasterMain (argc=3, argv=0xa0ced50) at postmaster.c:1023
> #18 0x081b69d6 in main (argc=3, argv=0xa0ced50) at main.c:188
>
> What other information could help track down this problem?
>
> 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-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
I've read the code, for what that's worth, which isn't much. I just
tried out this patch on a fresh checkout of CVS TIP and found:
EXPLAIN WITH RECURSIVE t(i) AS (VALUES(1::int) UNION ALL SELECT i+1 FROM t WHERE i < 5) SELECT * FROM t AS t1 JOIN t AS t2 USING(i);
QUERY PLAN
-------------------------------------------------------------------------------------
Hash Join (cost=0.08..0.16 rows=2 width=4)
Hash Cond: (t1.i = t2.i)
-> Recursion on t1 (cost=0.00..0.06 rows=2 width=4)
-> Append (cost=0.00..0.04 rows=2 width=4)
-> Values Scan on "*VALUES*" (cost=0.00..0.01 rows=1 width=4)
-> Recursive Scan on t (cost=0.00..0.00 rows=1 width=4)
Filter: (i < 5)
-> Hash (cost=0.06..0.06 rows=2 width=4)
-> Recursion on t2 (cost=0.00..0.06 rows=2 width=4)
-> Append (cost=0.00..0.04 rows=2 width=4)
-> Values Scan on "*VALUES*" (cost=0.00..0.01 rows=1 width=4)
-> Recursive Scan on t (cost=0.00..0.00 rows=1 width=4)
Filter: (i < 5)
(13 rows)
When I try to execute the query without the EXPLAIN, having attached a debugger
to the back-end, I get.
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x08192dcd in ExecQual (qual=0xa183824, econtext=0xa183230, resultForNull=0 '\0') at execQual.c:4513
4513 expr_value = ExecEvalExpr(clause, econtext, &isNull, NULL);
(gdb) i s
#0 0x08192dcd in ExecQual (qual=0xa183824, econtext=0xa183230, resultForNull=0 '\0') at execQual.c:4513
#1 0x08199b23 in ExecScan (node=0xa1831a4, accessMtd=0x81a6bb0 <RecursivescanNext>) at execScan.c:131
#2 0x081a6ba9 in ExecRecursiveScan (node=0xa1831a4) at nodeRecursivescan.c:48
#3 0x08192320 in ExecProcNode (node=0xa1831a4) at execProcnode.c:380
#4 0x081a6923 in RecursionNext (node=0xa17fe18) at nodeRecursion.c:68
#5 0x08199a83 in ExecScan (node=0xa17fe18, accessMtd=0x81a6840 <RecursionNext>) at execScan.c:68
#6 0x081a6839 in ExecRecursion (node=0xa17fe18) at nodeRecursion.c:116
#7 0x081923e0 in ExecProcNode (node=0xa17fe18) at execProcnode.c:339
#8 0x081a1c13 in MultiExecHash (node=0xa17fcc4) at nodeHash.c:94
#9 0x081a28b9 in ExecHashJoin (node=0xa17b654) at nodeHashjoin.c:159
#10 0x081922d8 in ExecProcNode (node=0xa17b654) at execProcnode.c:395
#11 0x081901db in standard_ExecutorRun (queryDesc=0xa15c334, direction=ForwardScanDirection, count=0) at execMain.c:1271
#12 0x08240dc4 in PortalRunSelect (portal=0xa15631c, forward=1 '\001', count=0, dest=0xa1733d8) at pquery.c:937
#13 0x082420e6 in PortalRun (portal=0xa15631c, count=2147483647, isTopLevel=1 '\001', dest=0xa1733d8, altdest=0xa1733d8,
completionTag=0xbfcacaea "") at pquery.c:793
#14 0x0823d0a7 in exec_simple_query (
query_string=0xa12fc9c "WITH RECURSIVE t(i) AS (VALUES(1::int) UNION ALL SELECT i+1 FROM t WHERE i < 5) SELECT * FROM t AS t1 JOIN t AS t2 USING(i);") at postgres.c:977
#15 0x0823e84c in PostgresMain (argc=4, argv=0xa0d0dac, username=0xa0d0d7c "shackle") at postgres.c:3559
#16 0x0820957f in ServerLoop () at postmaster.c:3238
#17 0x0820a4e0 in PostmasterMain (argc=3, argv=0xa0ced50) at postmaster.c:1023
#18 0x081b69d6 in main (argc=3, argv=0xa0ced50) at main.c:188
What other information could help track down this problem?
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-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
The reviewer registered at the Wiki is David Fetter and I believe he
is reading the patches. Michael Makes has contributed the ecpg
part. So apparently he is knowing the ecpg part at least.
I know the patch is huge. Reviewers, please let me know if you have
any question about the code. I would like to do anything for helping
the review.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Modified Files:
--------------
pgrpm:
ChangeLog (r1.11 -> r1.12)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgrpm/pgrpm/ChangeLog.diff?r1=1.11&r2=1.12)
pgheader.c (r1.29 -> r1.30)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgrpm/pgrpm/pgheader.c.diff?r1=1.29&r2=1.30)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Modified Files:
--------------
pgrpm:
pgheader.c (r1.28 -> r1.29)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgrpm/pgrpm/pgheader.c.diff?r1=1.28&r2=1.29)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Wed, Jul 23, 2008 at 5:08 PM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> I promised to have an in-depth look at the archives before to spend time on
> my ideas for $subject, but failed to do so.
I guess that means you missed both the original discussion at
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php and
my initial patch in that direction and subsequent discussion at
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php then
:(.
There were two core components to my idea of modules/packages:
- Separation of installation at an OS level (RPM/yum, deb/dpkg, MSI
installer etc) and installation into a database. The intention was a)
to standardize package installation generally so that users didn't
have to read n different sets of installation instructions for n
different packages, and b) so that a db owner could install into their
own database any module that had been installed on the system, even if
that might include e.g. C functions that they otherwise would not be
able to install without being a superuser.
- Have dependency tracking so that pg_dump could emit e.g. "LOAD
MODULE foo;" rather than all the different instructions to recreate
the module.
So the proposed installation procedure would be more along the lines of:
yum install postgresql-module-postgis
echo "load module postgis" | psql mydb
My intention was to use whatever native package manager was
appropriate for your distro rather than trying to recreate CPAN,
although some people in the original discussion wanted to go down that
route.
The patch that I provided didn't do any of the dependency stuff yet -
I had been investigating various ways to do it automagically, although
I haven't worked on it for a little while. It may be that the straight
forward explicit declaration that you have here is a better way to do
it.
I didn't have versioning and interdependencies between modules yet,
although it's an obvious extension to the idea.
> A package can also host variables, which visibility are
> package global: any SQL into the package can refer directly to package
> variables.
That was way out of scope for my more modest suggestion - I certainly
wasn't going to change pl/pgsql semantics. For example, how do those
variables behave upon a transaction rollback?
> Now, what would be really good to have would be this pg_pkg command I was
> dreaming about in another -hacker mail:
This turns into recreating CPAN. I like the idea of a "blessed" set of
packages, but would rather not require all postgresql users to have a
full build environment (especially on windows) and have to replace
their native packaging solution. It seems that you agree that
fetching/installing should be separate from loading/installing into
the database. Good. Some posters on the original thread were
suggesting that the fetch/install step should somehow do the database
installation as well, which sounded like a huge can of worms.
I think that we can come up with a package/module format that allows
installation at the OS level without demanding a whole set of download
/ build machinery. If someone then wants to build that and have it
install packages, then fine, but we definitely should not require it
to be able to install stuff.
Look forward to your comments
Cheers
Tom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Modified Files:
--------------
pgrpm:
pgheader.c (r1.27 -> r1.28)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgrpm/pgrpm/pgheader.c.diff?r1=1.27&r2=1.28)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
From demo:
====================================
create or replace
function i_have_global_priv(int4) returns bool as '
declare
priv_id alias for $1;
connection_id int4;
result bool;
begin
select into connection_id, result
veil_int4_get(''person_id''),
veil_bitmap_testbit(''global_context'', priv_id);
if connection_id is null then
return false;
else
return result;
end if;
end;
' language plpgsql
stable
security definer;
====================================
and then
====================================
create view privileges(
privilege_id,
privilege_name) as
select privilege_id,
privilege_name
from vdemo_owner.privileges
where i_have_global_priv(10001);
^^^^^^^^^^^^^^^^^^^^^^^^^^
====================================
so we have function call (with even more selects within it) for EACH row in the protected table!
And the planner cannot use indexes and optimize query - it will be FULL SCAN on a table.
Inshort veil scheme is:
create view data_view(
field1,
field2) as
select field1,
field12
from table
where decision_function(something_about_record);
create or replace
function decision_function returns bool as '
begin
select_permisssions_from_some_tables_check_and_return_yes_or_now
...
end
I wish to avoid this: apllication atumatically create temporary view for each user's session with the built in checks like in this example:
create view data_view(
field1,
field2) as
select field1,
field12
from table
where
field1 = value1 and field2 = value2 ... other conditions; (or what ever condition or even joins I want)
So planner will have all information for optimization.
Certainly conditions will undertake from some policy tables,
but it will occur ONLY ONCE at view creation at session begining.
I only would like to have flexible way to create/modify views on the fly.
And Vail is not in standart PostgreSQL...
And I don't wanna (re)compiling anything
--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
Bonjour,
Ci-joint un message qui a pris la mauvaise direction.
#########
- -------- Message original --------
Sujet: [Presque HS] Nagios & Ndoutils & PostgreSQL
Date: Wed, 23 Jul 2008 00:38:34 +0200
De: Sébastien BROCHET <sebastien.brochet@domoveil.fr>
ndoutils est un module de nagios permettant (en gros) le stockage dans
une base de données.
Initialement cet outils était destiné à utiliser Mysql pour se faire.
La version 1.4b7 publiée fin 2007 propose le support de postgres !
la blague : les scripts d'initialisation de la base ne sont livrés que
pour mysql !
1 - Quelqu'un aurait t'il fait une réécriture de ces scripts ?
2 - Cela intéresserait t'il quelqu'un de se joindre à moi pour le faire
si tel n'était pas le cas ?
Cdlt,
Séb
########
Librement,
- --
Stéphane Schildknecht
PostgreSQLFr : http://www.postgresql.fr
Venez nous rencontrer le 4 octobre lors du plus important événement
PostgreSQL francophone : http://www.pgday.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIhuCnA+REPKWGI0ERAlowAKCJbiKh07C2ZrwhPEMGbCP6SJ3UqACcCbyB
w+kWCB52IhO1cpihYOaaD14=
=uqri
-----END PGP SIGNATURE-----
--
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
For example we have table for spamassassin preferences, and user spamassassin.
I don't want spamassassin user to see user database (passwords, ...)
So I use function:
CREATE OR REPLACE FUNCTION get_sa_preferences( VARCHAR )
RETURNS SETOF sa_preferences AS $$
DECLARE
rec RECORD;
BEGIN
SELECT user_id, sa_group
INTO rec
FROM users
JOIN emails USING (user_id)
WHERE email = $1;
IF FOUND THEN
IF rec.user_id != rec.sa_group AND rec.sa_group != 0 THEN
RETURN QUERY SELECT *
FROM sa_preferences
WHERE user_id = rec.sa_group;
END IF;
RETURN QUERY SELECT *
FROM sa_preferences
WHERE user_id = rec.user_id;
END IF;
END;
$$ LANGUAGE 'plpgsql' SECURITY DEFINER;
There is no grants for spamassassin user to tables users, emails.
spamassassin user can get preferences but can't see users database.
If I change or add new features to system, I don't need to change
queries on every server, just replace function.
I want use functions like this for every lookup - domains, users,
forwards, many more
Most important I want to use plpgsql functions for web functions, like
add_email, chenge_password, ...
Is there sql injections possible with those functions, should I check,
quote $1, $2 variables?
How about performance? Is there some overhead when using plpgsql?
How are transactions used within plpgsql functions?
If I run query:
SELECT * FROM get_sa_preferences('artis.caune@gmail.com');
I'm actually running?:
BEGIN;
SELECT * FROM get_sa_preferences('artis.caune@gmail.com');
COMMIT;
Can I use:
BEGIN;
SELECT * FROM add_user('description');
SELECT * FROM add_email('user@domain');
SELECT * FROM add_settings('setting1', 'setting2');
... other functions ...
COMMIT;
thanks,
Artis
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
As you certainly know by now, Postgres-R introduces an additional
manager process. That one is forked from the postmaster, so are all
backends, no matter if they are processing local or remote transactions.
That led to a communication problem, which has originally (i.e. around
Postgres-R for 6.4) been solved by using unix pipes. I didn't like that
approach for various reasons: first, AFAIK there are portability issues,
second it eats file descriptors and third it involves copying around the
messages several times. As the replication manager needs to talk to the
backends, but they both need to be forked from the postmaster, pipes
would also have to go through the postmaster process.
Trying to be as portable as Postgres itself and still wanting an
efficient messaging system, I came up with that imessages stuff, which
I've already posted to -patches before [1]. It uses shared memory to
store and 'transfer' the messages and signals to notify other processes
(the so far unused SIGUSR2, IIRC). Of course this implies having a hard
limit on the total size of messages waiting to be delivered, due to the
fixed size of the shared memory area.
Besides the communication between the replication manager and the
backends, which is currently done by using these imessages, the
replication manager also needs to communicate with the postmaster: it
needs to be able to request new helper backends and it wants to be
notified upon termination (or crash) of such a helper backend (and other
backends as well...). I'm currently doing this with imessages as well,
which violates the rule that the postmaster may not to touch shared
memory. I didn't look into ripping that out, yet. I'm not sure it can be
done with the existing signaling of the postmaster.
Let's have a simple example: consider a local transaction which changes
some tuples. Those are being collected into a change set, which gets
written to the shared memory area as an imessage for the replication
manager. The backend then also signals the manager, which then awakes
from its select(), checks its imessages queue and processes the message,
delivering it to the GCS. It then removes the imessage from the shared
memory area again.
My initial design features only a single doubly linked list as the
message queue, holding all messages for all processes. An imessages lock
blocks concurrent writing acces. That's still what's in there, but I
realize that's not enough. Each process should better have its own
queue, and the single lock needs to vanish to avoid contention on that
lock. However, that would require dynamically allocatable shared memory...
As another side node: I've had to write methods similar to those in
libpq, which serialize and deserialize integers or strings. The libpq
functions were not appropriate because they cannot write shared memory,
instead they are designed to flush to a socket, if I understand
correctly. Maybe, these could be extended or modified to be usable there
as well? I've been hesitating and rather implemented separate methods in
src/backed/storage/ipc/buffer.c.
Comments?
Regards
Markus Wanner
[1]: last time I published IMessage stuff on -patches, WIP:
http://archives.postgresql.org/pgsql-patches/2007-01/msg00578.php
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Sounds awful. Thanks for the review, will fix.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Agreed.
We should also examine the basic thinking of the index.
My understanding is that it dynamically resizes hash as the index grows.
If we already believe the only benefit would come when the index is
large, having special handling for small tables seems like a waste of
time because we will never use it in those contexts.
So starting the hash at a fairly large size makes more sense than it
might otherwise seem to.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> >> Now *any* error inside transaction will trigger auto rollback for
> >> *all* inserts so I don't need to explicitly issue conditional
> >> rollback? Also is "begin/commit transaction" == "start/end
> >> transaction"??
>
> What if something gets an invalid state (eg you expect a record to have
> 'active = 156' but it's something else).
>
> So in some cases yes you'll need to do a rollback. On the other hand, if
> you don't explicitly do a commit, everything is rolled back.
>
> Yes "begin" == "start transaction" and "commit" == "end transaction".
"commit" really is not a well-chosen name for what it is. It
is often clearer to think in terms of the triple
begin
rollback
end
where begin/end are the standard begin/end transaction
commands while rollback is only ever needed when you detect
a condition someplace logically *outside* the transaction
itself and based on that want to undo the transaction that
is in progress.
Because no matter whether you issue commit or rollback - if
there was an error *inside* the transaction it'll rollback
in any case (unless the error was handled somehow).
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
