Re-reading in the morning rather that late at night...
Josh Berkus j...@agliodbs.com writes:
=== installing and removing an extension
begin;
install extension foo with search_path = foo;
Needs install file location:
INSTALL EXTENSION foo FROM '~/downloads/foo' WITH search_path =
On Wed, Jun 24, 2009 at 9:43 PM, Josh Berkusj...@agliodbs.com wrote:
== OS Filesystem Interaction
PostgreSQL already provides standard paths where to install extensions by
means of PGXS, and distribution packagers have been able to adapt those.
We
should just stick with this, meaning the
Dave Page dp...@pgadmin.org writes:
On Wed, Jun 24, 2009 at 9:43 PM, Josh Berkusj...@agliodbs.com wrote:
Also, this means that we'll want to make sure that PGXS is included in all
existing packages of PostgresQL. Is it?
Apologies if I missed further discussion on this - I'm somewhat
On Thu, Jun 25, 2009 at 9:58 AM, Dimitri Fontainedfonta...@hi-media.com wrote:
Dave Page dp...@pgadmin.org writes:
PGXS is essentially useless on Windows unless you're compiling your
own code using Mingw/msys, which will be a miniscule percentage of
users. Our installers for 8.3 and above are
On Wed, 2009-06-24 at 01:19 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Is the %d actually in the right place here?
errmsg(picksplit method for %d column of index \%s\ failed,
attno + 1, RelationGetRelationName(r))
No, any native speaker of English would say
Dave Page wrote:
On Thu, Jun 25, 2009 at 9:58 AM, Dimitri Fontainedfonta...@hi-media.com
wrote:
Dave Page dp...@pgadmin.org writes:
PGXS is essentially useless on Windows unless you're compiling your
own code using Mingw/msys, which will be a miniscule percentage of
users. Our installers
Magnus Hagander mag...@hagander.net writes:
We do it for Makefiles in contrib, so in theory it should be doable.
Excellent!
The problem is, I think, that the Makefile format is way too flexible.
You can write anything as shell commands in there, and there is no way
we can ever parse that and
On Thu, 2009-06-25 at 13:50 +0900, Fujii Masao wrote:
I wonder why pg_standby requires libpq.so.5. We should get rid of
PG_LIB settings from contrib/pg_standby/Makefile? Here is the patch
to do so.
Am I missing something?
It's good. Checked and ready to apply.
--
Simon Riggs
Short patch to
1. disable pg_standby -l
One line change only appropriate for this stage of release
2. Remove mention of -l and link from docs
pg_standby -l is still accepted, just does nothing (for now).
Existing code maintained in case we backpatch a fix for linking problem
at a later
Simon Riggs wrote:
On Thu, 2009-06-25 at 13:50 +0900, Fujii Masao wrote:
I wonder why pg_standby requires libpq.so.5. We should get rid of
PG_LIB settings from contrib/pg_standby/Makefile? Here is the patch
to do so.
Am I missing something?
It's good. Checked and ready to apply.
Is
Simon Riggs wrote:
Short patch to
1. disable pg_standby -l
One line change only appropriate for this stage of release
2. Remove mention of -l and link from docs
pg_standby -l is still accepted, just does nothing (for now).
Existing code maintained in case we backpatch a fix for
Hi,
On Thu, Jun 25, 2009 at 8:33 PM, Magnus Hagandermag...@hagander.net wrote:
Is there any reason not to remove the include directory in PG_CPPFLAGS
as well? Seems it is equally unused...
No. I agree to remove PG_CPPFLAGS.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
Fujii Masao wrote:
Hi,
On Thu, Jun 25, 2009 at 8:33 PM, Magnus Hagandermag...@hagander.net wrote:
Is there any reason not to remove the include directory in PG_CPPFLAGS
as well? Seems it is equally unused...
No. I agree to remove PG_CPPFLAGS.
The second question is, is it worth doing
Magnus Hagander wrote:
Fujii Masao wrote:
On Thu, Jun 25, 2009 at 8:33 PM, Magnus Hagandermag...@hagander.net wrote:
Is there any reason not to remove the include directory in PG_CPPFLAGS
as well? Seems it is equally unused...
No. I agree to remove PG_CPPFLAGS.
The second question is, is
Magnus Hagander mag...@hagander.net writes:
The second question is, is it worth doing this so extremely late in the
8.4 development? After mentioning it quickly in an offlist discussion
with Heikki, I think our conclusion was that we should wait with this
until the tree opens for 8.5.
+1.
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
The second question is, is it worth doing this so extremely late in the
8.4 development? After mentioning it quickly in an offlist discussion
with Heikki, I think our conclusion was that we should wait with this
until the tree opens
Hi,
On Thu, Jun 25, 2009 at 10:09 PM, Magnus Hagandermag...@hagander.net wrote:
The second question is, is it worth doing this so extremely late in the
8.4 development? After mentioning it quickly in an offlist discussion
with Heikki, I think our conclusion was that we should wait with this
Simon Riggs si...@2ndquadrant.com writes:
--- 610,621
}
break;
case 'l': /* Use link */
! /*
! * Link feature disabled,
Magnus Hagander mag...@hagander.net writes:
On Thu, Jun 25, 2009 at 9:58 AM, Dimitri Fontainedfonta...@hi-media.com
wrote:
Is it possible to design this part of the extension system with only
PGXS in mind and later adapt the windows toolsuite?
We do it for Makefiles in contrib, so in theory
On Thu, 2009-06-25 at 09:51 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
--- 610,621
}
break;
case 'l': /* Use link */
! /*
!
On Wed, Jun 24, 2009 at 11:51:57AM +0200, Boszormenyi Zoltan wrote:
attached is our latest patch extending ECPG:
Just as a short explanation, the older versions were sent to me only and I
reviewed them. I haven't found time to to review this one yet though.
Michael
--
Michael Meskes
Michael at
On Jun 25, 2009, at 2:21 AM, Dave Page wrote:
Is it possible to design this part of the extension system with only
PGXS in mind and later adapt the windows toolsuite?
Anything is possible :-). Better to ask someone with more perl
expertise than me how much effort it might take to have the
On Jun 25, 2009, at 7:16 AM, Tom Lane wrote:
The problem is, I think, that the Makefile format is way too
flexible.
I think the contrib makefiles are considered to be our standard test
suite for PGXS. If a 3rd-party makefile is doing anything not
represented in contrib, it's not guaranteed
On 6/25/09, David E. Wheeler da...@kineticode.com wrote:
On Jun 25, 2009, at 2:21 AM, Dave Page wrote:
Is it possible to design this part of the extension system with only
PGXS in mind and later adapt the windows toolsuite?
Anything is possible :-). Better to ask someone with more perl
David E. Wheeler da...@kineticode.com writes:
Is there no platform-independent build system we could take advantage
of?
There's been some talk of using cmake, but the conversion effort would
be massive, and I'm not sure the benefits would warrant it.
regards, tom lane
On Jun 25, 2009, at 10:10 AM, Tom Lane wrote:
Is there no platform-independent build system we could take advantage
of?
There's been some talk of using cmake, but the conversion effort would
be massive, and I'm not sure the benefits would warrant it.
Might it be worthwhile just for the
Simon Riggs si...@2ndquadrant.com writes:
Will do, thanks. Patch to cleanup as advised is attached.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
In view of the rather significant bugs that were just found in WAL
recovery (see discussion of bug #4879), the core team has concluded
it would be irresponsible to wrap 8.4.0 without some more time for
review and testing of the proposed fixes. We will postpone the release
at least one day to
With 8.4RC1, I get the following error with the SQL below.
ERROR: failed to find conversion function from unknown to character varying
SQL state: XX000
SELECT 0 AS C1, cast('a' as varchar) AS C2
UNION ALL
SELECT 1 AS C1, X.XX AS C2
FROM ( SELECT NULL AS XX ) AS X
WHERE TRUE = FALSE
Compare
Eric Miller eric_g_mil...@yahoo.com writes:
With 8.4RC1, I get the following error with the SQL below.
ERROR: failed to find conversion function from unknown to character varying
Every PG version since 7.1 complains about that query, because it's
underspecified. Cast the NULL to something
Hi,
contrib/dblink seems to have no treatments for query cancels.
It causes the following issues:
(1) Users need to wait for completion of remote query.
Requests for query cancel won't be delivered to remote servers.
(2) PGresult objects will be memory leak. The result is not released
Hi Stephen,
What would be really useful would be best case and worst case
scenarios.
I've put together some data from a microbenchmark of the bcTrulen
function, patched and unpatched.
As for best-case, if you have a long string of trailing spaces, we can
go through them at theoretically one
Jeremy Kerr j...@ozlabs.org writes:
I've put together some data from a microbenchmark of the bcTrulen
function, patched and unpatched.
Uh, where's the data?
In the worst cases, I see a 53% cost increase on x86 (with the string
'aaa ') and a 97% increase on PowerPC ('a ').
So, it all
Tom,
I've put together some data from a microbenchmark of the bcTrulen
function, patched and unpatched.
Uh, where's the data?
If you're after the raw data for a run, I've put it up:
http://ozlabs.org/~jk/projects/db/data/bctruelen.csv
I've also packaged up the quick-and-dirty benchmark
This patch adds support DAC security checks on largeobjects.
Enhanced GRANT/REVOKE statement allows to set SELECT (read) and
UPDATE (write) permission on individual largeobjects.
At the creation time, it checks ACL_CREATE on the schema object.
Currently, a largeobject does not have any human
35 matches
Mail list logo
