--On 25. Januar 2010 11:39:21 +0900 KaiGai Kohei kai...@ak.jp.nec.com
wrote:
(echo CREATE TABLE t (a int);
for i in `seq 0 9`; do
echo CREATE TABLE s$i (b int) INHERITS(t);
for j in `seq 0 9`; do
echo CREATE TABLE v$i$j (c int) INHERITS(s$i);
for k in `seq 0 9`;
--On 27. Januar 2010 15:42:45 -0500 Robert Haas robertmh...@gmail.com
wrote:
Bernd (or anyone), feel free to take a look in parallel. More eyes
would be helpful...
I've planned to look at this tomorrow when i'm back in office.
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing
--On 24. Februar 2010 16:01:02 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
One objection to this is that it's not very clear to the user when
pg_stop_backup has finished with actual work and is just waiting for the
archiver, ie when is it safe to hit control-C? Maybe we should emit a
backup
--On 10. April 2010 09:26:41 +0200 Boszormenyi Zoltan z...@cybertec.at
wrote:
The above is quite reproducable, pg_ctl stop -m immediate
usually inflated my serial sequence, but I had two occasions
when not. The 69 - 70 was one. The inflated increase is always 33:
AFAIKS sequences are
--On 23. April 2010 14:34:45 -0700 Steve Atkins st...@blighty.com wrote:
Or more generally an ability to set aliases via .psqlrc similar to \set,
maybe?
\alias \d- = \d
\alias \d = \d+
You mean something like this?
http://archives.postgresql.org/pgsql-patches/2008-04/msg5.php
--
--On 7. Mai 2010 09:48:53 -0500 Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I think it goes beyond tweaking -- I think we should have a bald
statement like don't turn this off unless you're OK with losing the
entire contents of the database cluster. A brief listing of some
cases
--On 7. Mai 2010 19:49:15 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Bernd Helmle maili...@oopsware.de writes:
I've recently even started to wonder if the performance gain with
fsync=off is still that large on modern hardware. While testing large
migration procedures to a new version some
--On 18. Mai 2010 23:20:26 +0200 Jesper Krogh jes...@krogh.cc wrote:
That was it. Knowing what the problem was I had no problem finding it in
the release notes.
May I ask whats the reason is for breaking the compatibillity?
Efficency, if i am allowed to call it this way. The new hex
While looking at Jaime's last temp_tablespaces GUC patch, i've got some
concerns about it's current implementation:
1)
The code claims that OIDs of temp tablespaces couldn't be cached, therefore
it is parsing and
re-reading the GUCs in GetTempTablespace() with SplitIdentifierNames() over
and
--On Freitag, Mai 25, 2007 10:49:29 + Jaime Casanova
[EMAIL PROTECTED] wrote:
No, because the RemovePgTempFiles() call in PostmasterMain() will
remove all tmp files at startup.
Hmm isn't RemovePgTempFiles() called on postmaster startup only? What will
happen if a temp tablespace is out
--On Freitag, Mai 25, 2007 00:02:06 + Jaime Casanova
[EMAIL PROTECTED] wrote:
the original patch is from Albert Cervera =)
Ah, missed that, thanks ;)
sounds good. can we see the new patch?
Attached tablespace.c.diff shows my current changes to use an OID lookup
list.
the
--On Dienstag, Juni 05, 2007 16:04:44 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Is it correct that a user with CREATEROLE privilege but without CREATEDB
privilege can create a user with *CREATEDB* privilege, thus bypassing his
original restrictions? This sequence doesn't look right:
--On Montag, Juni 04, 2007 15:34:14 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
The reason I'm thinking per-transaction is that we could tie this to
setting up a cached list of tablespace OIDs, which would avoid the
overhead of repeat parsing and tablespace validity checking. We had
rejected
--On Montag, Juni 04, 2007 15:34:14 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Perhaps a reasonable compromise could work like this: at the first point
in a transaction where a temp file is created, choose a random list
element, and thereafter advance cyclically for the duration of that
Short question:
While playing around with various postgresql installations i recognized
that pg_dump complaints even within major-releases about different
minor-numbers, such as:
pg_dump: server version: 8.2.4; pg_dump version: 8.2.0
I thought we are safe against pg_dump changes within a
--On Freitag, Juni 29, 2007 15:32:19 +0200 Magnus Hagander
[EMAIL PROTECTED] wrote:
On Fri, Jun 29, 2007 at 03:09:30PM +0200, Bernd Helmle wrote:
Short question:
While playing around with various postgresql installations i recognized
that pg_dump complaints even within major-releases about
--On Montag, August 03, 2009 12:38:48 -0400 Robert Haas
robertmh...@gmail.com wrote:
Let's get back to focusing on the patch that is actually under
consideration here.
Status Report: I will finish documentation and review tomorrow and will
mark this patch for committer review.
--
Thanks
--On Montag, August 03, 2009 23:43:08 +0200 Bernd Helmle
maili...@oopsware.de wrote:
Status Report: I will finish documentation and review tomorrow and will
mark this patch for committer review.
Here's my latest reviewed version of Pavel's patch with adjusted
documentation per latest
--On Dienstag, August 04, 2009 10:28:48 -0400 Tom Lane t...@sss.pgh.pa.us
wrote:
While I've been poking at the pg_dump issues, it's occurred to me that
changing the default would be a great forcing function for finding out
any lurking problems.
+1
--
Thanks
Bernd
--
--On 4. August 2009 20:22:05 +0200 Pavel Stehule pavel.steh...@gmail.com
wrote:
Named notation has different algorithm for function detection then
positional notation. There are not exist variadic parameters (because
these parameters hasn't individual names). So only packed variadic
--On Mittwoch, August 05, 2009 05:28:55 +0200 Pavel Stehule
pavel.steh...@gmail.com wrote:
At least, we need to document that both notations behaves different in
this case.
+1
Here again a patch version with updated documentation. I will stop
reviewing this patch now and mark this ready
--On Donnerstag, August 06, 2009 19:10:47 -0400 Tom Lane
t...@sss.pgh.pa.us wrote:
I'm starting to look at this now, and my very first reaction was
what in the world is a leaky list?. I'm not sure I like the
data structure itself, but the terminology is certainly completely
unhelpful.
Hrm,
--On 9. August 2009 12:27:53 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Now that I've started to read this patch ... exactly what is the
argument for allowing a mixed notation (some of the parameters named
and some not)? ISTM that just serves to complicate both the patch
and the user's-eye
--On 9. August 2009 13:00:07 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Mph. Does Oracle adopt the same semantics for what a mixed call means?
I had a look at the Oracle documentation while reviewing this patch, and i
thought we are pretty close to what they do. Maybe Pavel can comment more
--On 27. August 2009 11:34:29 +0200 Boszormenyi Zoltan z...@cybertec.at
wrote:
make -C ../../../contrib/spi refint.so autoinc.so
make[3]: Entering directory
`/home/zozo/Schönig-számlák/lucent/postgresql-8.3.5/contrib/spi'
gcc -m32 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
--On 15. September 2009 22:41:59 +0100 Simon Riggs si...@2ndquadrant.com
wrote:
http://wiki.postgresql.org/images/0/01/Hot_Standby_Recovery_Functions.pdf
This doesn't work for me, it seems the correct link is
http://wiki.postgresql.org/images/1/10/Hot_Standby_Recovery_Functions.pdf
?
--On 17. September 2009 23:00:12 +0300 Peter Eisentraut pete...@gmx.net
wrote:
f the name is a problem, why not change the name? What you are
proposing above is effectively a very elaborate name change, so why not
go for a simpler one?
I don't like the solution by using -o initdb options
--On 25. August 2009 22:17:38 -0400 Alvaro Herrera
alvhe...@commandprompt.com wrote:
I'm just posting in case somebody has thoughts on the UI part of it.
Other things that need fixed:
- need to figure out locking for roles; this stuff must be synchronized
with role drop
- pg_shadow and
--On 20. September 2009 22:56:53 -0400 Robert Haas robertmh...@gmail.com
wrote:
So is this ready to commit, or what?
Not yet, see the comments Alvaro did upthread. Please note that i'm still
reviewing this one and i hope to post results tomorrow (there wasn't plenty
of free time over
--On 21. September 2009 13:42:21 +0200 Bernd Helmle maili...@oopsware.de
wrote:
--On 20. September 2009 22:56:53 -0400 Robert Haas
robertmh...@gmail.com wrote:
So is this ready to commit, or what?
Not yet, see the comments Alvaro did upthread. Please note that i'm still
reviewing
--On 23. September 2009 14:10:39 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I looked the patch over quickly, and I think it will be fine once
Bernd's comments are addressed. In particular I agree with the
objection to the name pg_setting as being confusingly close to
pg_settings. But
--On 27. September 2009 21:59:37 -0400 Robert Haas robertmh...@gmail.com
wrote:
Bernd,
Can you review this new version and mark this as Ready for Committer
if it looks OK, or else respond with comments and set it back to
Waiting on Author?
Seems Alvaro forgot to include
--On 28. September 2009 19:02:34 -0400 Alvaro Herrera
alvhe...@commandprompt.com wrote:
Seems Alvaro forgot to include pg_db_role_setting.h, it doesn't
compile anymore with this error:
Here they are.
I'll see if i can get to it tonight. I'm currently travelling, so it could
be delayed
--On 30. September 2009 13:19:53 -0400 Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it would be helpful if you could post ONE patch with all the
changes and all the new files in the diff. AIUI, the patch is now
split across three separate emails. :-(
That's correct, here it
--On 1. Oktober 2009 17:22:06 -0400 Alvaro Herrera
alvhe...@commandprompt.com wrote:
- ALTER ROLE ... IN DATABASE is missing some documentation. If you
want, i can work on this.
Please.
Here's a patch for this. I've kept it separately, so it's easier for you to
merge it into
your
--On 1. Oktober 2009 17:22:06 -0400 Alvaro Herrera
alvhe...@commandprompt.com wrote:
- The patch as is has still some locking problems (AlterRoleSet()
has a XXX about that): I've managed to create dead entries for a
role or a database in pg_db_role_setting while altering and dropping
a
--On 5. Oktober 2009 09:51:29 +0300 Peter Eisentraut pete...@gmx.net
wrote:
The way forward with updatable views is triggers on views. I was going
to write something about that in the future. I haven't worked out all
the details.
In the mentioned discussion there was already the notion
--On 4. Oktober 2009 21:37:45 -0400 Robert Haas robertmh...@gmail.com
wrote:
This is the last I remember hearing of it, which seems to suggest that
only a week's worth of work (maybe a bit more for those of us who are
not Tom Lane) is needed:
--On 6. Oktober 2009 10:13:54 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00416.php
namely that CREATE OR REPLACE should leave the object having the
properties specified in the command.
Maybe when implementing this, it can be worth to
--On 20. Oktober 2009 10:49:33 -0700 David Fetter da...@fetter.org wrote:
track_activities (should be on)
track_counts (should be on)
update_process_title (should be on)
Removing all track* GUCs would only make sense if we are going to make
autovacuum mandatory, i think. And i thought
I just run across an issue with ALTER TABLE and inheritance (i don't know
wether this is of the same kind of issue KaiGai reported today, so i keep
it on a separate thread).
Consider the following workflow:
CREATE TABLE foo(id integer NOT NULL, val text NOT NULL);
CREATE TABLE
--On 4. November 2009 09:57:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
I think the
consensus was that the way to fix this (along with some other problems)
is to start representing NOT NULL constraints in pg_constraint, turning
attnotnull into just a bit of denormalization for performance.
--On 12. November 2009 15:48:44 + Greg Stark gsst...@mit.edu wrote:
I'm beginning to think the right solution is to reject the idea of
adding a payload to the NOTIFY mechanism and instead provide a queue
contrib module which provides the interface people want.
Isn't PgQ already the
--On 4. November 2009 09:57:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
I think the
consensus was that the way to fix this (along with some other problems)
is to start representing NOT NULL constraints in pg_constraint, turning
attnotnull into just a bit of denormalization for performance.
--On 13. November 2009 19:08:22 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
It looks to me like the code in AlterSetting() will allow an ordinary
user to blow away all settings for himself. Even those that are for
SUSET variables and were presumably set for him by a superuser. Isn't
this a
I'm just seeing these kind of compiler warnings in current HEAD:
pgstat.c: In function ‘pgstat_report_activity’:
pgstat.c:2276: warning: passing argument 1 of
‘__dtrace_probe$postgresql$statement__status$v1$63686172202a’ discards
qualifiers from pointer target type
There are more of them
--On Freitag, April 04, 2008 05:04:04 +1100 Brendan Jurd
[EMAIL PROTECTED] wrote:
For everyone else who hasn't read the original discussion on -patches,
here's a link into the archives:
http://archives.postgresql.org/pgsql-patches/2008-04/msg5.php
On Fri, Apr 4, 2008 at 4:19 AM, Tom
--On Freitag, April 04, 2008 06:52:37 +1100 Brendan Jurd
[EMAIL PROTECTED] wrote:
I didn't realise it would be that straightforward!
Stumbled across it during hacking...
You could probably also do away with psql_scan_slash_pushback()
(psqlcan.h, psqlcan.l) as it is only used by the code
--On Donnerstag, April 10, 2008 22:48:24 +0100 Gregory Stark
[EMAIL PROTECTED] wrote:
Well I feel like storing a query and resending it later is something
predictable which will work reliably. Storing a psql input line and
reinterpreting it later is surely going to cause weird things to
--On Freitag, April 11, 2008 13:53:11 -0500 Decibel! [EMAIL PROTECTED]
wrote:
As Bernd said, I see this as simple search and replace, and then stick it
in the command buffer. If you define an alias that calls itself, you
could end up with a stack overflow, same as with server functions.
The
It seems changes to the commit fest wiki pages are going to be overwritten
accidently when editing the page concurrently. At least, this occured to me
as i accidently removed entries done by Laurenz Albe and my changes were
overwritten by Alvaro Herrera again.
So developers need to be
--On Mittwoch, April 23, 2008 03:17:54 +1000 Brendan Jurd
[EMAIL PROTECTED] wrote:
I had a look into the history on the CommitFest page. It looks like
Alvaro unintentionally clobbered the previous five edits, which went
back about four hours. I've restored those changes now, but it is
Now that we have customizable segment sizes for heap and WAL at compilation
time i would like to have some runtime variables to query that information
(besides pg_controldata). I can imagine to have the following names:
segment_size: Reports heap segment size
wal_segment_size: Reports wal
--On Mittwoch, Juli 02, 2008 07:39:29 -0400 Ken Camann [EMAIL PROTECTED]
wrote:
I assume it would only really matter if you did this to
a pointer, and perhaps that is happening somewhere (but I doubt it
since postgres runs fine on 64-bit POSIX OSes). These would be easy
to fix, but very
--On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian [EMAIL PROTECTED]
wrote:
I'd like to implement them if we agree on them
Bernd, have you made any progress on this?
Here's a patch for this. I'll add it to the commit fest wiki page if it's
okay for you.
--
Thanks
--On Freitag, Juli 04, 2008 11:31:07 +0200 Stefan Kaltenbrunner
[EMAIL PROTECTED] wrote:
I just noticed that setting log_rotation_age to a value larger than 24
days results in rather weird output (I have not actually tested yet if
that affects the functionality too or just the output):
I'm about to add/cleanup some missing descriptions for aggregates and
functions (such as corr(), enum_first()) and discovered that stddev(),
min() and others doesn't have a pg_description entry, too. Is there a
reason for that? Maybe keep off redundant information from pg_description?
--
There's a behavior in pg_dump that annoyed me a little bit, the last few
times i had to deal with it:
Consider you have to dump a specific namespace only, you are going to use
pg_dump -n your_schema [-t tables].
I found it a common use case to restore this dump into a different schema
by
--On Montag, Juli 07, 2008 10:33:35 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
It seems like quite a useless change, since in general there will be
other qualified references in the dump that can't safely be removed.
IOW what you intend to do doesn't work anyway.
Hmm, If i want to restore just
--On Montag, Juli 07, 2008 11:09:56 -0400 Andrew Dunstan
[EMAIL PROTECTED] wrote:
I don't think in general we need to provide pg_dump with every possible
permutation of uses that can achieved with the construction of simple
tool chains.
I always feel the same. However, i thought it would be
--On Mittwoch, August 27, 2008 09:35:03 +0200 Grant Finnemore
[EMAIL PROTECTED] wrote:
I have a session pool, where all connections to the database are
obtained as a superuser. On issuing connections to the client, we
invoke either SET ROLE or SET SESSION AUTHORIZATION and switch to
a role
I've used above function to construct OpExpr expressions with equality
operators in the past, but it seems it was removed and there's no
replacement for it?
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
--On Freitag, November 02, 2007 10:54:45 + Gregory Stark
[EMAIL PROTECTED] wrote:
I think this module should be rewritten to depend more closely on the
Postgres source files. What I'm doing now is making an SRF in the style
of the pageinspect module which will read an arbitrary wal file
--On Dienstag, November 06, 2007 16:31:05 +0100 Peter Eisentraut
[EMAIL PROTECTED] wrote:
I noticed this problem in 8.2 and 8.3:
pei=# select mod( trunc( 1 ), 2 );
ERROR: 42883: function mod(double precision, integer) does not exist
LINE 1: select mod( trunc( 1 ), 2 );
^
It
--On Montag, November 12, 2007 18:10:12 +0530 Gokulakannan Somasundaram
[EMAIL PROTECTED] wrote:
http://jdbc.postgresql.org/documentation/head/query.html#query-with-curs
or
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Thanks Heikki. That answered my question. Can
While supporting a customer to increase recovery performance from its
backups i just realized that PostgreSQL never uses big maintenance_work_mem
settings. Even giving 10GB of RAM to maintenance_work_mem results in using
a fraction of memory (it switches to external sort after using around 2
--On Montag, November 26, 2007 13:02:14 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
... But isn't it worth to special case the
code in grow_memtuples() (and maybe other places where sort is likely to
use more RAM), so that we can remove this constraint on 64
--On Montag, November 26, 2007 21:41:33 +0100 I wrote:
--On Montag, November 26, 2007 13:02:14 -0500 Tom Lane
[EMAIL PROTECTED] wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
... But isn't it worth to special case the
code in grow_memtuples() (and maybe other places where sort is likely
--On Donnerstag, Februar 14, 2008 15:52:31 +1100 Brendan Jurd
[EMAIL PROTECTED] wrote:
Hello hackers,
psql's \du command currently does not list the INHERIT role attribute.
It does show the other privilege attributes (superuser, create role,
create db), and INHERIT seems like the kind of
--On Donnerstag, Februar 14, 2008 10:27:37 -0300 Alvaro Herrera
[EMAIL PROTECTED] wrote:
I wonder if it's possible to create a more compact output -- say, a
fixed-width column, with a letter for each enabled attribute, or a space
in the respective position when the attribute is disabled.
I saw this strange behavior due to a customer problem who managed to get
dumps which aren't restorable anymore:
CREATE TABLE foo(datum date);
INSERT INTO foo VALUES('-02-29');
INSERT 0 1
SELECT * FROM foo;
datum
---
0001-02-29 BC
(1 row)
COPY foo TO STDOUT;
0001-02-29 BC
--On Montag, Februar 25, 2008 12:00:05 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
regression=# select '0001-02-28 BC'::date + 1;
?column?
---
0001-02-29 BC
(1 row)
regression=# select '0002-02-28 BC'::date + 1;
?column?
---
0002-03-01 BC
(1 row)
I stepped
--On Montag, Februar 25, 2008 14:04:18 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
The other issue is whether to throw error for year zero, rather than
silently interpreting it as 1 BC. I can't recall whether that behavior
was intentional at the time, but given our current rather strict
--On Donnerstag, März 06, 2008 17:03:10 -0500 Bruce Momjian
[EMAIL PROTECTED] wrote:
Where are on updatable views?
I really want to have this one ready for 8.4, but i have nothing appliable
at the moment. Considering the amount of rework that needs to be done, i
hope i can provide an
--On 4. November 2009 09:57:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, this is a known issue. The ALTER should be rejected, but it is
not, because we don't have enough infrastructure to notice that the
constraint is inherited and logically can't be dropped. I think the
consensus was
--On 15. Juni 2010 20:51:21 -0700 Selena Deckelmann selenama...@gmail.com
wrote:
Confirmed that this tests fine against commit id
0dca7d2f70872a242d4430c4c3aa01ba8dbd4a8c
I also wrote a little test script and verified that it throws an error
when I try to remove a constraint from the
Consider the following small testcase:
BEGIN;
CREATE OR REPLACE FUNCTION upper(IN varchar, OUT varchar)
LANGUAGE SQL STRICT IMMUTABLE
AS
$$
SELECT pg_catalog.upper($1)::varchar;
$$;
CREATE TABLE foo(value varchar);
INSERT INTO foo SELECT 'helmle' FROM generate_series(1, 1000);
CREATE
--On 15. Juli 2010 18:02:10 +0200 Guillaume Lelarge
guilla...@lelarge.info wrote:
And would you add the complete syntax? I mean:
SHOW [OPEN] TABLES [FROM db_name] [LIKE 'pattern']
I'm wondering what one can do with the [FROM db_name] clause :)
And as soon as you have this, people want
--On 15. Juli 2010 15:52:24 -0400 Andrew Dunstan and...@dunslane.net
wrote:
FYI, MS-SQL does this stuff with some stored procedures. I regularly use
sp_columns to fiind out what I'm really being asked to interact with. See
http://msdn.microsoft.com/en-us/library/ms182764.aspx
Yeah,
--On 1. Mai 2010 23:09:23 -0400 Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
CREATE OR REPLACE is indeed much more complicated. In fact, for
tables, I maintain that you'll need to link with -ldwim to make it
work properly.
--On 21. Juli 2010 17:16:13 -0400 Robert Haas robertmh...@gmail.com wrote:
I get the same error message from concurrent CREATE TABLE commands
even without CINE...
S1:
rhaas=# begin;
BEGIN
rhaas=# create table foo (id int);
CREATE TABLE
S2:
rhaas=# begin;
BEGIN
rhaas=# create table foo (id
--On 16. Juni 2010 14:31:00 +0200 Bernd Helmle maili...@oopsware.de wrote:
There are some spelling and grammar errors in comments that I can help
fix if you want the help.
You're welcome. I have pushed my branch to my git repos as well, if you
like to start from there:
http
--On 17. August 2010 20:08:51 +0200 Erik Rijkers e...@xs4all.nl wrote:
How can I 'change OID'? This error comes out of an initial initdb run.
(There are several other test-instances on this machine (several
running), but with their own $PGDATA, $PGPORT. - they can't interfere
with each
--On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
maili...@oopsware.de wrote:
--On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas
robertmh...@gmail.com wrote:
Do you intend to submit an updated version of this patch for this
commitfest?
I'll do asap, i've updated
On Mon, Dec 22, 2008 at 8:53 AM, Bernd Helmle maili...@oopsware.de
wrote:
--On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
maili...@oopsware.de wrote:
Okay, i've finally managed to create an updated version with (hopefully)
all
issues mentioned by Robert adressed.
Hi Bernd
On Sun, Dec 28, 2008 at 9:29 AM, Bernd Helmle be...@oopsware.de wrote:
i would say check for negative attnums and deny that view to be
updateable because of SQL92 says in 11.19 view definition syntax
rule 6:
6) If the query expression is updatable, then the viewed table
--On Montag, Januar 05, 2009 17:12:27 -0800 Josh Berkus j...@agliodbs.com
wrote:
-- Automatic View Update Rules
I'm currently adressing the issues Jaime mentioned and will provide an
updated patch very soon.
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list
--On Sonntag, Dezember 28, 2008 15:29:58 +0100 Bernd Helmle
be...@oopsware.de wrote:
maybe the better solution is to not allow such a view to be updatable
Yes, it seems we have to check for target lists having negative attnums in
checkTree(). Another solution would be to simply ignore those
--On Freitag, Januar 09, 2009 13:20:57 +0100 Bernd Helmle
maili...@oopsware.de wrote:
That means, View1 consists of View2 and so on. What happens now if
someone is going to change View3, so that it's not updatable anymore?
What the patch actually does is, scanning all relations/views involved
--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle
maili...@oopsware.de wrote:
I've decided to check updatability of all involved views during view
creation. Please find attached a new version with all other open issues
adressed.
Oops, forgot to track some files in my new git branch
--On Montag, Januar 12, 2009 14:48:46 +0200 Peter Eisentraut
pete...@gmx.net wrote:
gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
-g -I../../../src/include -I/sw/include/libxml2 -I/sw/include -c -o
--On Donnerstag, Januar 15, 2009 17:51:35 +0200 Peter Eisentraut
pete...@gmx.net wrote:
This patch has annoyed me twice in two days now, and similarly with other
people I know. Having to type \dfS now is about the worst loss of
usability in psql that I can recall. Can we reconsider or revert
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
pete...@gmx.net wrote:
* It is not clear how automatic rules and manual DO ALSO rules should
interact. A manual DO ALSO rule will currently clear out an automatic
INSTEAD rule, which I find to be illogical.
My intentional feeling
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
pete...@gmx.net wrote:
Here is my updated patch based on yours.
Outstanding issues, as far as I can see, are:
Critical:
* Updatability check must reject views where the select list references
the same column more than once.
--On Donnerstag, Januar 22, 2009 15:30:35 -0500 Andrew Dunstan
and...@dunslane.net wrote:
Am I the only person who gets regularly annoyed by pg_get_viewdef()
outputting the target list as one long line? I'd like it to put one
target per line, indented, if pretty printing.
No, so +1 from
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
In short, I don't feel that this was ready to be applied. It's probably
fixable with a week or so's work, but do we want to be expending that
kind of effort on it at this stage of the release cycle?
Uh well, i'd be
--On 23. Januar 2009 17:32:55 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
In short, I don't feel that this was ready to be applied.
Uh well, i'd be happier if such review
--On 23. Januar 2009 18:02:55 -0500 Jaime Casanova
jcasa...@systemguards.com.ec wrote:
to be honest, i feel like that was commented in the last (or the last
before the last) release cycle well this patch originally appears.
I know that i've changed something in the operator lookup code
--On 23. Januar 2009 18:07:38 -0500 Jaime Casanova
jcasa...@systemguards.com.ec wrote:
and what about default values? if we redirect we will have to use the
table's default (something i like) and AFAIU we won't have the ability
to change it for the view at least not without manually create
--On 23. Januar 2009 21:18:19 -0500 Robert Haas robertmh...@gmail.com
wrote:
In the future, I think we should have an expectation that resubmits
within the same CommitFest should happen within a week, and that if no
revision is forthcoming within two weeks the patch is declared dead
(and
101 - 200 of 405 matches
Mail list logo
