Hello
you can't to use parameters inside literal. There hasn't any sense (to
8.3, 8.4 will support USING).
you have to use serialisation to string and quoting.
some like
CREATE OR REPLACE FUNCTION foo(int[])
RETURNS SETOF int AS $$
DECLARE r record;
BEGIN
FOR r IN EXECUTE
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
The other one is it has two kind of reader permissions (select and
use).
The select permission is applied when user tries to read tables/columns
and its contents are returned to the user.
The use permission is applied when user tries to read
Peter Eisentraut wrote:
I have been thinking about this for a great while now. I am not yet
comfortable with how we manage the access rights here. We have
restricted access to the user mappings catalog to hide passwords, but it
is not entirely clear why a password must be stored in a user
On Wed, 2009-03-04 at 15:58 +0200, Heikki Linnakangas wrote:
Fujii Masao wrote:
Currently, the startup process ignores SIGHUP.
The attached patch allows the startup process to re-read config file:
when SIGHUP arrives, the startup process also receives the signal
from postmaster and
Dne 3.03.09 22:55, Tom Lane napsal(a):
One idea that comes to mind is to replace the entries like
{abort, ABORT_P, UNRESERVED_KEYWORD},
with macro calls
PG_KEYWORD(abort, ABORT_P, UNRESERVED_KEYWORD),
and then the frontend build of the file could define the macro
to ignore
Hi,
On Thu, Mar 5, 2009 at 6:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
Should we reload recovery.conf also?
I think no for now. At least the parameters which specify the recovery target
should not be changed during recovery. On the other hand, restore_command
maybe can be set safely, but
On Thu, 2009-03-05 at 19:52 +0900, Fujii Masao wrote:
Hi,
On Thu, Mar 5, 2009 at 6:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
Should we reload recovery.conf also?
I think no for now. At least the parameters which specify the recovery target
should not be changed during recovery.
Simon Riggs wrote:
On Thu, 2009-03-05 at 19:52 +0900, Fujii Masao wrote:
Hi,
On Thu, Mar 5, 2009 at 6:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
Should we reload recovery.conf also?
I think no for now. At least the parameters which specify the recovery target
should not be changed
Fujii Masao wrote:
BTW, I found that backup.sgml still had the description of log_restartpoints.
Here is the patch to remove it.
Thanks, I had put that in the Open Items list so that we remember to do
that before release.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Tom Lane escreveu:
=?ISO-8859-1?Q?Andr=E9_Volpato?= andre.volp...@ecomtecnologia.com.br writes:
First I tryed to configure with no options, and then make throw this:
float.c:74: error: static declaration of 'cbrt' follows non-static declaration
Dickson S. Guedes escreveu:
2009/3/4 Andr Volpato andre.volp...@ecomtecnologia.com.br:
Im trying to install postgres 8.3.6 at AIX 5.3, and I got a declaration
error that I presume its related to this [1] thread.
Heres some info:
- Bladecenter IBM JS22 - PowerPC_POWER6 quad 4GHZ
Hi,
we have come across a theoretical problem with a GIS database,
which I think worth discussing.
The database table is partitioned, it's already larger than 30TB.
The table is partitioned over the PostGIS (overlaps) operator.
However, when SELECTing from that table, it goes through all
Joshua Tolley wrote:
On Wed, Mar 04, 2009 at 10:28:42AM +0100, Magnus Hagander wrote:
Joshua Tolley wrote:
On Wed, Mar 04, 2009 at 09:43:55AM +0100, Magnus Hagander wrote:
So. I've updated the comment, and applied your patch. Thanks!
What would it take to get it applied to a few earlier
Zdenek Kotala wrote:
Dne 3.03.09 22:55, Tom Lane napsal(a):
One idea that comes to mind is to replace the entries like
{abort, ABORT_P, UNRESERVED_KEYWORD},
with macro calls
PG_KEYWORD(abort, ABORT_P, UNRESERVED_KEYWORD),
and then the frontend build of the file could define
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Seems doable.
Attached.
The TWO_MEMBER_SCANKEYWORD business seems a bit dangerous --- if the
header file is read without having #defined that correctly, bad things
will happen. It might be better to leave that out,
On Thu, Mar 5, 2009 at 1:12 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Seems doable.
Attached.
The TWO_MEMBER_SCANKEYWORD business seems a bit dangerous --- if the
header file is read without having #defined that
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch fixes the matter.
It fixes up attribute number of child relation when it is extracted.
Thanks! It looks good to me, but we'll need Tom or some other
committer to review it and commit it, of course.
Thanks again,
KaiGai Kohei wrote:
Heikki, Thanks for your comments.
Heikki Linnakangas wrote:
Ok, I've taken a quick look at this too. My first impression is that
this is actually not a very big patch. Much much smaller than I was
afraid of. It seems that dropping the row-level security and the other
If we remove the support for regular, non-bitmap, index scans with GIN,
that could be cleaned up as well. Even if we don't do that, gingetbitmap
should not error when the bitmap becomes lossy, but just return the
lossy bitmap.
Changes since 28.2
Xavier Bugaud wrote:
On Thursday 05 March 2009 12:31:17 Heikki Linnakangas wrote:
Xavier Bugaud wrote:
This trivial patch allows PostgreSQL to understand the MUST (Mauritius
Summer Time) time zone that is in used since 2008-11.
...
*** src/timezone/tznames/Default1 May 2008 20:05:08
Magnus Hagander mag...@hagander.net writes:
Yeah, the big question is if we want to backport something like this at
all... Thoughts?
The issue never even came up before, so I'd vote to not take any risks
for it. How often do people mess up the protections on pg_hba.conf?
Stephen Frost sfr...@snowman.net writes:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch fixes the matter.
It fixes up attribute number of child relation when it is extracted.
Thanks! It looks good to me, but we'll need Tom or some other
committer to review it and
On Thu, Mar 05, 2009 at 09:47:55AM -0500, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Yeah, the big question is if we want to backport something like this at
all... Thoughts?
The issue never even came up before, so I'd vote to not take any risks
for it. How often do
The GIN_EXTRACT_VALUE macro returns a pointer to a static 'entries'
variable. That doesn't seem safe. Is it really never possible to have to
two GIN searches in a plan, both calling and using the value returned
by extractValue simultaneously? In any case that seems like a pretty
weak
On Wed, Mar 04, 2009 at 02:35:52PM -0800, Josh Berkus wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
I think this sounds a lot like another request for a set of system views
with nicer names.
What's the state of the newsysviews project, anyway? I don't recall
hearing
Guillaume Smet ha scritto:
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut pete...@gmx.net wrote:
The question is how you want to implement this in a data type independent
fashion. You can't assume that increasing the typmod is a noop for all data
types.
Sure. See my previous answer on
On Tue, 3 Mar 2009, Andrew Dunstan wrote:
Date: Tue, 03 Mar 2009 11:02:35 -0500
From: Andrew Dunstan and...@dunslane.net
To: o...@pyrenet.fr
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_restore -m failing
o...@pyrenet.fr wrote:
hi all,
After Andrew
I've recently run into a problem with a datatype whose operators are
based on functions not marked IMMUTABLE. Although there might be good
reasons to have such a thing, it seems like it might be a valuable
warning message if you create an operator based on an non-IMMUTABLE
function. Comments?
-
On Thu, 2009-03-05 at 11:27 -0700, Joshua Tolley wrote:
I've recently run into a problem with a datatype whose operators are
based on functions not marked IMMUTABLE. Although there might be good
reasons to have such a thing, it seems like it might be a valuable
warning message if you create an
Joshua Tolley eggyk...@gmail.com writes:
I've recently run into a problem with a datatype whose operators are
based on functions not marked IMMUTABLE. Although there might be good
reasons to have such a thing, it seems like it might be a valuable
warning message if you create an operator based
Took bugs list off, as this is clearly not a bug.
Matteo Beccati p...@beccati.com wrote:
I recently had a similar problem when I added some domains to the
application. ALTER TABLE ... TYPE varchar_dom was leading to a full
table rewrite even though the underlying type definition were
On Thursday 05 March 2009 18:04:42 Joshua Tolley wrote:
As an aside, is access() adequately portable, ok to use within the
backend, etc.? I just sort of took a shot in the dark.
Using access() is usually not a good idea. In this case it would be better to
check the return of the actual open()
Peter Eisentraut wrote:
On Thursday 05 March 2009 18:04:42 Joshua Tolley wrote:
As an aside, is access() adequately portable, ok to use within the
backend, etc.? I just sort of took a shot in the dark.
Using access() is usually not a good idea. In this case it would be better
to
check
On Thu, Mar 5, 2009 at 10:47 AM, Matteo Beccati p...@beccati.com wrote:
Guillaume Smet ha scritto:
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut pete...@gmx.net wrote:
The question is how you want to implement this in a data type independent
fashion. You can't assume that increasing the
Alvaro Herrera alvhe...@commandprompt.com writes:
Hopefully this is the last version of this patch.
A few more comments would help --- in particular the header comment
for kwlist.h should explain that the calling file is supposed to define
PG_KEYWORD appropriately for its needs. I also wonder
Thomas Pundt escreveu:
Hi,
André Volpato schrieb:
[...]
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
[...]
utils/SUBSYS.o ../../src/timezone/SUBSYS.o ../../src/port/libpgport_srv.a
-Wl,-bE:../../src/backend/postgres.imp -lld -o postgres
ld: 0711-317
Jaime Casanova jcasa...@systemguards.com.ec wrote:
ALTER TABLE ... TYPE does cause a table rewrite even if new_type =
old_type, and that is actually useful...
for example when you add a fillfactor to an existing table that
fillfactor will not affect the existing data until you rewrite the
Dickson S. Guedes escreveu:
2009/3/4 Andr Volpato andre.volp...@ecomtecnologia.com.br:
Im trying to install postgres 8.3.6 at AIX 5.3, and I got a declaration
error that I presume its related to this [1] thread.
Heres some info:
- Bladecenter IBM JS22 - PowerPC_POWER6 quad 4GHZ
Fujii Masao masao.fu...@gmail.com writes:
BTW, I found that backup.sgml still had the description of log_restartpoints.
Here is the patch to remove it.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Jaime Casanova jcasa...@systemguards.com.ec wrote:
the table will be scanned but not rewritten
That can still be a very long time on some tables.
And there would still be the issue of dodging all the brickbats thrown
at me by developers whose tools use the system tables to limit the
number
2009/3/5 André Volpato andre.volp...@ecomtecnologia.com.br:
Guedes my friend, that doesnt work either.
:(
First, I put back only the define my_cbrt line in float.c, and then tryed
to configure with all the flags above.
The Undefined symbols errors keep coming.
As Thomas pointed out, I
On Thu, Mar 5, 2009 at 2:46 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
now, back to the problem... is not easier to define a column as TEXT
and to put a check to constraint the length? if you wanna change the
constraint that will be almost free
Thanks for the interesting
On Thu, Mar 5, 2009 at 3:27 PM, Xuân Baldauf
xuan--2009.03--submitbug--support--postgresql@baldauf.org wrote:
Well, while this behaviour is well-known for PostgreSQL, this is actually an
abuse of syntax. If there are legitimate requirements for rewriting a table,
then there should be
Jaime Casanova wrote:
On Thu, Mar 5, 2009 at 10:47 AM, Matteo Beccati p...@beccati.com wrote:
Guillaume Smet ha scritto:
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut pete...@gmx.net wrote:
The question is how you want to implement this in a data type independent
On Thu, Mar 05, 2009 at 08:19:05PM +0100, Magnus Hagander wrote:
Peter Eisentraut wrote:
On Thursday 05 March 2009 18:04:42 Joshua Tolley wrote:
As an aside, is access() adequately portable, ok to use within the
backend, etc.? I just sort of took a shot in the dark.
Using access() is
Teodor Sigaev teo...@sigaev.ru writes:
Changes since 28.2
(http://archives.postgresql.org/message-id/499b0ffa.8040...@sigaev.ru)
- fixes/changes pointed by Robert
(http://archives.postgresql.org/pgsql-hackers/2009-02/msg00987.php)
- gingetbitmap will never throw error about lossiness of
All,
We've been carrying this warning in our docs since 7.4:
The key word ABSTIME is ignored for historical reasons: In very old
releases of PostgreSQL, invalid values of type abstime were emitted as
Invalid Abstime. This is no longer the case however and this key word
will likely be dropped
Hello all,
i'm playing around with the isn contrib module and ran into an
annoying problem. The module defines an is_valid() function which
obviously is intended to check the validity of an ISBN number. Makes
sense to have such a function because if the user mistyped the number
the application
I was wondering why USING clause is not supported in pl/pgsql dynamic
statement. Serialization is the option I tried to avoid, but it seems there is
no better approach available.
Just to say a few more about the usage of my function. In dag_tree_1, (rid,
rtid) is the primary key, which
On Thu, Mar 5, 2009 at 6:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Attached is the remainder of the patch with relatively minor fixes.
The main change I made is to get rid of the changes in gincostestimate;
I agree with Robert that it's probably inappropriate to consider the
current
On Thu, Mar 5, 2009 at 8:32 PM, Sophie Yang yangsop...@yahoo.com wrote:
I was wondering why USING clause is not supported in pl/pgsql dynamic
statement. Serialization is the option I tried to avoid, but it seems there
is no better approach available.
Just to say a few more about the usage
The attached patch contains the probes (originally came from Theo
Schlossnagle) that were removed from the previous submitted patch.
Zdenek had some concerns about the way the probes were implemented
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01168.php. If
there are specific
I don't see how the problem can be solved by merging the function logic into
the calling function. The int[][] array is supplied by user, and I still have
the issue to pass it into a dynamic statement, no matter in which function,
unless I serialize it to string and deserialize back to
In response to Andreas 'ads' Scherbaum :
Hello all,
test=# select is_valid('978-3-937514-69-7'::isbn13);
is_valid
--
t
(1 row)
Nice advertisement for your book...
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header)
GnuPG-ID:
54 matches
Mail list logo
