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 i
2008/12/17 Robert Haas :
> On Tue, Dec 16, 2008 at 9:18 PM, Tom Lane wrote:
>> "Robert Haas" 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_pr
"Brendan Jurd" 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 like "cannot
On Tue, Dec 16, 2008 at 9:18 PM, Tom Lane wrote:
> "Robert Haas" 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
>> nu
On Wed, Dec 17, 2008 at 12:23 PM, Tom Lane 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 there's a big probl
Tom Lane writes:
> ITAGAKI Takahiro 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 N
ITAGAKI Takahiro 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
> arguments to "%s" fo
Andrew Dunstan 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 connect to tcp:pos
Hi,
On Tue, Dec 16, 2008 at 7:21 PM, Simon Riggs 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 fsyn
"Pavel Stehule" 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 to cope, or else
gen
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.
Tha
"Robert Haas" 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.
That's been co
Hi,
On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor 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 much as we
> absol
On Tue, Dec 16, 2008 at 3:25 PM, Tom Lane 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 actually create M
Tom Lane wrote:
> KaiGai Kohei 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 retur
Gregory Stark 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 that the point of a
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
"Brendan Jurd" writes:
> On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane 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 approac
On Wed, Dec 17, 2008 at 11:07 AM, Tom Lane 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 intuitively expect
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 D
Tom Lane writes:
> Gregory Stark 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 ve
Gregory Stark 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
> an empty array.
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 fe
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 j
Tom Lane 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 parameters eith
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 variadi
Gregory Stark 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 significant amount of wor
Tom Lane writes:
> Josh Berkus 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 in Postgres and we are no
Josh Berkus 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 parameters; it
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 fo
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
James Mansion 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
> integrated and turned on in th
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.
T
"David E. Wheeler" 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 been
>> falsifi
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 allowed
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 sch
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
"David E. Wheeler" 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 really chang
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 defaul
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:
http://www.postgresql.org/mailpref
"David E. Wheeler" 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 the same t
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
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 |
Vie
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 fo
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
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':
> storage/buffer/bufmgr.o(.
On Fri, 2008-11-28 at 12:45 -0500, Tom Lane wrote:
> Simon Riggs 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 need to kick
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 -
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 ex
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
2008/12/16 Rushabh Lathia :
>
>
> On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule
> wrote:
>>
>> 2008/12/16 Rushabh Lathia :
>> >
>> > When we find the (pathpos < prevResult->pathpos) into
>> > FuncnameGetCandidates(), we just replacing the prevResult with the
>> > newResult.
>> >
>> > While replac
KaiGai Kohei 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 InvalidOid.
> (The co
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:
http://www.postgresql.org/mailpref/pgsql-hack
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 abou
Shri 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 (pgsql-hackers@post
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 machine.
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 Herrerahttp
On Tue, Dec 16, 2008 at 5:35 PM, Pavel Stehule wrote:
> 2008/12/16 Rushabh Lathia :
> >
> > 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 th
2008/12/16 Rushabh Lathia :
>
> 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 care for the arg
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 dep
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 pgsql-hac
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
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
> >
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 eg.
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 cas
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 wa
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
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 maint
68 matches
Mail list logo