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)
Gn
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 int[][].
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 reco
On Thu, Mar 5, 2009 at 8:32 PM, Sophie Yang 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 of my function.
On Thu, Mar 5, 2009 at 6:35 PM, Tom Lane 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 pending-list size during
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 identif
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 ca
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
Teodor Sigaev 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 bitmap, it wil
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 a
Jaime Casanova wrote:
> On Thu, Mar 5, 2009 at 10:47 AM, Matteo Beccati wrote:
>
>> Guillaume Smet ha scritto:
>>
>>> On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut wrote:
>>>
The question is how you want to implement this in a data type independent
fashion. You can't
On Thu, Mar 5, 2009 at 3:27 PM, Xuân Baldauf
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 explicit syntax for such a feature, like "ALTER TABLE
> ... R
On Thu, Mar 5, 2009 at 2:46 PM, Kevin Grittner
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 suggestion. I'm not sure I'
2009/3/5 André Volpato :
> 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 think my AIX is missing lib
>>> Jaime Casanova 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 of characters a user is a
Fujii Masao 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 changes to your subscri
Dickson S. Guedes escreveu:
2009/3/4 André Volpato :
I´m 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.
Here´s some info:
- Bladecenter IBM JS22 - PowerPC_POWER6 quad 4GHZ 64 bits
- AIX 5.3.0
- Postgresql 8
>>> Jaime Casanova 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
> table and a convenien
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 ERR
Alvaro Herrera 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 whether Greg
isn't right th
On Thu, Mar 5, 2009 at 10:47 AM, Matteo Beccati wrote:
> Guillaume Smet ha scritto:
>> On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut 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
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
>
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(
Took bugs list off, as this is clearly not a bug.
>>> Matteo Beccati 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
exactly
> the sam
Joshua Tolley 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 on an non-IMMU
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
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?
- Jo
On Tue, 3 Mar 2009, Andrew Dunstan wrote:
Date: Tue, 03 Mar 2009 11:02:35 -0500
From: Andrew Dunstan
To: o...@pyrenet.fr
Cc: pgsql-hackers list
Subject: Re: [HACKERS] pg_restore -m failing
o...@pyrenet.fr wrote:
hi all,
After Andrew corrected the bug I found on pg_restore (-C -m misbehavi
Guillaume Smet ha scritto:
> On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut 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 -hackers
On Wed, Mar 04, 2009 at 02:35:52PM -0800, Josh Berkus wrote:
> Tom Lane wrote:
>> Magnus Hagander 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 much ab
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 assumptio
On Thu, Mar 05, 2009 at 09:47:55AM -0500, Tom Lane wrote:
> Magnus Hagander 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 th
Stephen Frost 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 commit it, o
Magnus Hagander 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?
regards, tom la
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 -
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
(http://archives.postgresql.org/message-id/499b0f
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
chang
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,
On Thu, Mar 5, 2009 at 1:12 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Alvaro Herrera 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 happ
Tom Lane wrote:
> Alvaro Herrera 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, always define the
>
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
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 e
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
parti
Dickson S. Guedes escreveu:
2009/3/4 André Volpato :
I´m 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.
Here´s some info:
- Bladecenter IBM JS22 - PowerPC_POWER6 quad 4GHZ 64 bits
- AIX 5.3.0
- Postgresql 8
Tom Lane escreveu:
=?ISO-8859-1?Q?Andr=E9_Volpato?= 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
After some googling, I find Br
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
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 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.
Why not
On Thu, 2009-03-05 at 19:52 +0900, Fujii Masao wrote:
> Hi,
>
> On Thu, Mar 5, 2009 at 6:28 PM, Simon Riggs 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.
Why not?
> On
Hi,
On Thu, Mar 5, 2009 at 6:28 PM, Simon Riggs 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 I'm not sure if it's
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 ign
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 postmas
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
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
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
'
54 matches
Mail list logo
