ITAGAKI Takahiro wrote:
The chained triggers would have better flexibilty, and the auto expanding
trigger would have better usability. I'm not sure about performance
because expanding child partitions is not always faster than chained
calls of triggers.
I think chained triggers are hard to
Hi
This is srujan and I am beginner of postgresql 8.1 and I have
just stopped using mysql and i would like to use the dump (.sql file)
created in it. I would like transfer the databases in my sql to postgresql
8.1. Please do reply. I am waiting for it.
Thanks in Advance
In response to sai srujan :
Hi
This is srujan and I am beginner of postgresql 8.1 and I have
just stopped using mysql and i would like to use the dump (.sql file)
created in it. I would like transfer the databases in my sql to postgresql
8.1.
Please do reply. I am waiting
I found a strange behavior on the recent v8.4devel with/without
SE-PostgreSQL patch set. Can you reproduce the following behavior?
When I use UPDATE statement with RETURNING clause which contains
references to tableoid system column, it returns InvalidOid.
(The correct valus is 16384 in this
On Tue, 2008-12-16 at 12:36 +0900, Fujii Masao wrote:
So from my previous list
1. We sent the message to standby (A)
2. We received the message on standby
3. We wrote the WAL to the WAL file (B)
4. We fsync'd the WAL file (C)
5. We CRC checked the WAL commit record
6. We applied
Dear friends,
I am trying to import db from oracle to pgsql,
meanwhile facing a difficulty during importing oracle numeric(38) to pgsql
numeric(38) column, Because in oracle that column is unique, but PGsql not
able to correctly identify different and unique values with numeric(38)
field.
for
Peter Eisentraut wrote:
Robert Lor wrote:
The attached patch contains a couple of fixes in the existing probes
and includes a few new ones.
- Fixed compilation errors on OS X for probes that use typedefs
Could you explain what these errors are about? I don't see any errors
on my
2008/12/16 Rushabh Lathia rushabh.lat...@gmail.com:
On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2008/12/16 Rushabh Lathia rushabh.lat...@gmail.com:
When we find the (pathpos prevResult-pathpos) into
FuncnameGetCandidates(), we just replacing the
Bruce Momjian wrote:
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
when thinking of REASSIGNED OWNED people tend to think about tables
rather than about CONNECT rights.
i would suggest to make DROP ROLE just kill the role unless there is a
real object depending on it.
2008/12/16 Rushabh Lathia rushabh.lat...@gmail.com:
When we find the (pathpos prevResult-pathpos) into
FuncnameGetCandidates(), we just replacing the prevResult with the
newResult.
While replacing the previous with new we do not replace the args. I think in
case of default we need to take
Added to TODO:
Allow dropping of a role that has connection rights
* http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php
---
Hans-Juergen Schoenig wrote:
good morning,
some days ago i
On 2008-12-16, at 07:58, ITAGAKI Takahiro wrote:
server says INSERT 0 row though rows are inserted into child
tables.
Technically this is correct since 0 rows were inserted in the parent
table.
Yes, but users expect non-0 result normally. Some O/R mapping tools
also checks the result
Fujii Masao escribió:
Since there are many TODO items, I'm worried about the deadline.
When is the deadline of this commit fest? December 31st? first half
of January? ...etc?
November 1st was the deadline. We're now in feature freeze.
--
Alvaro Herrera
On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
2008/12/16 Rushabh Lathia rushabh.lat...@gmail.com:
When we find the (pathpos prevResult-pathpos) into
FuncnameGetCandidates(), we just replacing the prevResult with the
newResult.
While replacing the
Robert Lor wrote:
Bruce Momjian wrote:
Should I apply this or hold it for 8.5?
I think it should go into 8.4 as it also fixes existing problems.
I am seeing the following error when linking the backend on a BSD machine:
./../src/port/libpgport_srv.a -lssl -lcrypto -lgetopt
Shri shripa...@gmail.com writes:
When i enter first data into column (using EMS SQL MANAGER),it converts it
to 1.111444E35
I think you need to complain to EMS.
regards, tom lane
PS: this is not a hacker-grade question.
--
Sent via pgsql-hackers mailing list
In response to Shri :
Dear friends,
I am trying to import db from oracle to pgsql,
meanwhile facing a difficulty during importing oracle numeric(38) to pgsql
numeric(38) column, Because in oracle that column is unique, but PGsql not
able
to correctly identify different and unique values
KaiGai Kohei kai...@ak.jp.nec.com writes:
I found a strange behavior on the recent v8.4devel with/without
SE-PostgreSQL patch set. Can you reproduce the following behavior?
When I use UPDATE statement with RETURNING clause which contains
references to tableoid system column, it returns
On Fri, 2008-11-28 at 12:45 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2008-11-28 at 11:44 -0500, Tom Lane wrote:
I hadn't been following the discussion closely enough to know what the
problem is.
When we replay an AccessExclusiveLock on the standby we
Bruce Momjian wrote:
I am seeing the following error when linking the backend on a BSD machine:
./../src/port/libpgport_srv.a -lssl -lcrypto -lgetopt -ldl -lutil -lm -o
postgres
storage/buffer/bufmgr.o: In function `ReadBuffer_common':
Robert Lor wrote:
Peter Eisentraut wrote:
Robert Lor wrote:
The attached patch contains a couple of fixes in the existing probes
and includes a few new ones.
- Fixed compilation errors on OS X for probes that use typedefs
Could you explain what these errors are about? I don't see any
Bruce Momjian wrote:
Should I apply this or hold it for 8.5?
I think it should go into 8.4 as it also fixes existing problems.
-Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Robert Lor wrote:
The attached patch contains a couple of fixes in the existing probes and
includes a few new ones.
- Fixed compilation errors on OS X for probes that use typedefs
Could you explain what these errors are about? I don't see any errors
on my machine.
--
Sent via
Bruce Momjian wrote:
I am seeing the following error when linking the backend on a BSD machine:
The updated patch attached should fix this problem. My bad for
overlooking this.
-Robert
Index: src/backend/access/transam/xlog.c
Consider
create function foo(f1 int, f2 int = 42, f2 int = 43) ...
create view v1 as select foo(11);
In CVS HEAD this gives
regression=# \d v1
View public.v1
Column | Type | Modifiers
+-+---
foo| integer |
View definition:
SELECT foo(11, 42, 43) AS
On Dec 16, 2008, at 9:25 PM, Tom Lane wrote:
Consider
create function foo(f1 int, f2 int = 42, f2 int = 43) ...
create view v1 as select foo(11);
In CVS HEAD this gives
regression=# \d v1
View public.v1
Column | Type | Modifiers
+-+---
foo| integer |
View
I saw on a summary for 8.4 that there's a generic function for use as a
before row trigger that will elide null updates (ie replacement with an
identical row).
I can see that this is great - but I was wondering if it should be more
integrated and turned on in the db schema.
Trivially, doing
David E. Wheeler da...@kineticode.com writes:
On Dec 16, 2008, at 9:25 PM, Tom Lane wrote:
I'm not sure we can do much to fix it, though. It'd probably be
possible to have the rewriter or planner insert the default
expressions, instead of the parser; but that creates its own issues.
Would
You could add it to here -- note that if we decide it isn't worth it it'll
just get removed.
Which category would you recommend? Optimizer / Executor?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Dec 16, 2008, at 10:15 PM, Tom Lane wrote:
Would the same thing happen for a prepared statement that calls the
function? Or another function?
Prepared statements and functions don't have such a problem, because
they don't have a long-lived parsetree representation. If you change
the
David E. Wheeler da...@kineticode.com writes:
On Dec 16, 2008, at 10:15 PM, Tom Lane wrote:
I'm not too thrilled about it. One thing to consider is that with the
default gone, it might be that there is some other function that
matches
the textual call better than this one. But we can't
I attached contrib module which is base of preupgrade script. It should be part
of 8.4, but it will be required for 8.4-8.5 upgrade.
This part contains space reservation for heap/toast relations. The idea is that
relation is read and each block is checked if there is enough free space. Tuples
James Mansion wrote:
I saw on a summary for 8.4 that there's a generic function for use as
a before row trigger that will elide null updates (ie replacement with
an identical row).
I can see that this is great - but I was wondering if it should be
more integrated and turned on in the db
On Dec 16, 2008, at 10:36 PM, Tom Lane wrote:
I haven't really thought through the consequences of this, but one
thing
we could consider doing to tamp down the damage is to prohibit
changing
the number of defaultable parameters of an existing function, ie treat
pronargdefaults as not
David E. Wheeler da...@kineticode.com writes:
On Dec 16, 2008, at 10:36 PM, Tom Lane wrote:
... The point here would be to ensure that function replacement
couldn't change the parser's decisions about whether a function matches
a call or not; which is the case in existing releases, but has
Andrew Dunstan wrote:
I don't follow what you're saying.
If an update is skipped by a trigger, nothing new is written to disk,
and there should be nothing to vacuum from it. That's why this trigger
can speed up certain update queries enormously.
OK I'll try again.
Suppose we do an update.
James Mansion ja...@mansionfamily.plus.com writes:
I saw on a summary for 8.4 that there's a generic function for use as a
before row trigger that will elide null updates (ie replacement with an
identical row).
I can see that this is great - but I was wondering if it should be more
And while we're on the subject ... as the patch stands, it lets you
provide defaults for polymorphic parameters, as in
regression=# create function eq (f1 anyelement, f2 anyelement default 42)
returns bool as 'select $1 = $2' language sql;
CREATE FUNCTION
regression=# select eq(now(),now());
eq
Tom Lane wrote:
Consider
create function foo(f1 int, f2 int = 42, f2 int = 43) ...
create view v1 as select foo(11);
In CVS HEAD this gives
regression=# \d v1
View public.v1
Column | Type | Modifiers
+-+---
foo| integer |
View definition:
SELECT
Josh Berkus j...@agliodbs.com writes:
Huh? Shouldn't changing a function which a view depends on require a
rebuild of the view?
There is no such concept as a rebuild of the view.
That is, I think we should treat changing the defaults the same as we
would changing the number and type of
Tom Lane t...@sss.pgh.pa.us writes:
Josh Berkus j...@agliodbs.com writes:
That is, I think we should treat changing the defaults the same as we
would changing the number and type of parameters; it kicks off a
dependency check and requires a CASCADE.
Dream on ... there is no such facility
Gregory Stark st...@enterprisedb.com writes:
We could say that changing the type of a default argument for a polymorphic
argument isn't allowed just like changing the return value.
The point I was trying to make is that allowing defaults for polymorphic
args at all is going to cause a very
Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary case for variadic
parameters is a bit weird already:
regression=# create function fv (f1 int, f2
Tom Lane t...@sss.pgh.pa.us writes:
A related point is that, because the current code forbids a default
for a variadic, you can't do something like
create function foo (f1 int, f2 int default = 42, f3 variadic int[] =
array[]::int[])
ie there's no way to have defaults on the preceding
Tom Lane wrote:
Oh, and another thing --- should variadic parameters be defaultable?
The current patch doesn't allow it but it looks more like an oversight
than anything that was thought through. The boundary case for variadic
parameters is a bit weird already:
From a user perspective, if we
On Tuesday 16 December 2008 08:01:49 Alvaro Herrera wrote:
Fujii Masao escribió:
Since there are many TODO items, I'm worried about the deadline.
When is the deadline of this commit fest? December 31st? first half
of January? ...etc?
November 1st was the deadline. We're now in feature
Gregory Stark st...@enterprisedb.com writes:
I'm inclined to think an implicit empty array makes the most sense. If a
function-writer wants to enforce a minimum number of arguments they can check
and throw an error.
The question arises though whether it's useful to have any default other than
Tom Lane t...@sss.pgh.pa.us writes:
Gregory Stark st...@enterprisedb.com writes:
We could say that changing the type of a default argument for a polymorphic
argument isn't allowed just like changing the return value.
The point I was trying to make is that allowing defaults for polymorphic
Greg,
Well honestly I don't see a terribly compelling use case for default arguments
altogether. Obviously they're just a programmer convenience and don't really
let anyone do anything they couldn't do without them.
The primary use case is for people who are porting applications from
other
On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument. If you buy that, then it
is sensible to forbid defaults for variadics,
Yep, +1 for this approach. I would
Brendan Jurd dire...@gmail.com writes:
On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM one could make a pretty good argument that this last case should
succeed, producing an empty-array argument. If you buy that, then it
is sensible to forbid defaults for variadics,
Thanks, applied.
---
Robert Lor wrote:
Bruce Momjian wrote:
I am seeing the following error when linking the backend on a BSD machine:
The updated patch attached should fix this problem. My bad for
Gregory Stark st...@enterprisedb.com writes:
So it's not like any use case for default polymorphic arguments is going to be
especially compelling either. But I don't see any reason it'll be any less
useful for polymorphic arguments than any other type.
Well, the reason it seems funny to me is
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
I found a strange behavior on the recent v8.4devel with/without
SE-PostgreSQL patch set. Can you reproduce the following behavior?
When I use UPDATE statement with RETURNING clause which contains
references to tableoid system column,
On Tue, Dec 16, 2008 at 3:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Does anyone think this is either unsurprising or desirable?
That's horrible.
I wonder whether the whole architecture is wrong here. Perhaps when a
function is created with N arguments of which M have default values,
we should
Hi,
On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor robert@sun.com wrote:
@@ -1313,12 +1318,14 @@ AdvanceXLInsertBuffer(bool new_segment)
* Have to write buffers while holding insert
lock. This is
* not good, so only write as
Robert Haas robertmh...@gmail.com writes:
I wonder whether the whole architecture is wrong here. Perhaps when a
function is created with N arguments of which M have default values,
we should actually create M entries in pg_proc: one for each possible
number of arguments from N-M up through N.
Hi all,
I have put a first draft of the wiki page dedicated to the table
partitioning development at
http://wiki.postgresql.org/wiki/Table_partitioning
The page is still incomplete and need much more work but it should be a
good starting point for discussions and a way to move forward.
Pavel Stehule pavel.steh...@gmail.com writes:
I'll write patch that block creating all ambiguous overloading.
Don't bother --- it's a useless solution because you can't guarantee
that concurrent insertions into pg_proc won't create an ambiguous
situation. You have to define the resolution rules
Hi,
On Tue, Dec 16, 2008 at 7:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2008-12-16 at 12:36 +0900, Fujii Masao wrote:
So from my previous list
1. We sent the message to standby (A)
2. We received the message on standby
3. We wrote the WAL to the WAL file (B)
4. We
Andrew Dunstan and...@dunslane.net wrote:
Thanks. The backtrace is kind of strange, but I might have found it.
Could you please update from CVS and re-run?
same result ;-(
Hi, I found the cause.
Segfault comes from the following lines.
[ecpg/test/connect/test1.pgc]
exec sql
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Hi, I found the cause.
...
Actual error occurs in vfprintf() because act-name can be NULL.
sprintf(..., %s, NULL) could work on some platform (the result is '(null)'),
but it crashes on Windows (msvcrt). We need to avoid passing NULLs as
Tom Lane t...@sss.pgh.pa.us writes:
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Hi, I found the cause.
...
Actual error occurs in vfprintf() because act-name can be NULL.
sprintf(..., %s, NULL) could work on some platform (the result is
'(null)'),
but it crashes on Windows
On Wed, Dec 17, 2008 at 12:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, I just realized that there's another fly in the ointment:
the current variadic code allows variadic anyarray, which is
equivalent to an appropriate number of anyelement arguments. If we
allow defaulting then
On Tue, Dec 16, 2008 at 9:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I wonder whether the whole architecture is wrong here. Perhaps when a
function is created with N arguments of which M have default values,
we should actually create M entries in
Brendan Jurd dire...@gmail.com writes:
So if I had these two functions ...
var1(a int, b variadic int[])
var2(a int, b variadic anyarray)
... it would be okay to write var1(8), which resolves as var1(8,
array[]::int[]). But if I tried to write var2(8) I'd get an error.
Maybe something
2008/12/17 Robert Haas robertmh...@gmail.com:
On Tue, Dec 16, 2008 at 9:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I wonder whether the whole architecture is wrong here. Perhaps when a
function is created with N arguments of which M have default
Zdenek Kotala wrote:
BTree space reservation is more complicated.
Do you need to pre-reserve the space for b-tree? I think you can just
split it at upgrade, in the new version. The problem with doing that for
heaps is that to move a heap tuple you need to update the index
pointers, but for
68 matches
Mail list logo
