Re: [HACKERS] Questions about patch "Table command"

--On Dienstag, November 04, 2008 17:12:15 -0800 Unicron <[EMAIL PROTECTED]> wrote: I am reviewer of Patch "Table command". I wanted to build code checked out from code repo got via rsyn, but I didn't find relating code in file "gram.y". Do i need to add the code to the file? The patch doesn't

Re: [HACKERS] Patch for ALTER DATABASE WITH TABLESPACE

--On Mittwoch, November 05, 2008 01:10:22 +0100 Guillaume Lelarge <[EMAIL PROTECTED]> wrote: Tom Lane a écrit : Guillaume Lelarge <[EMAIL PROTECTED]> writes: Should I provide a complete new patch with Bernd's and Tom's changes? Please --- it's better if you integrate it since you know the p

Re: [HACKERS] Patch for ALTER DATABASE WITH TABLESPACE

--On Mittwoch, November 05, 2008 19:20:07 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: No, I think that should just be a no-op. We don't for instance throw error when you ALTER OWNER to the existing owner. Hmm okay. When looking at this i was remembering the discussion we had for SET SCHEMA a

Re: [HACKERS] Patch for ALTER DATABASE WITH TABLESPACE

--On Donnerstag, November 06, 2008 11:35:54 +0100 Guillaume Lelarge <[EMAIL PROTECTED]> wrote: Guillaume Lelarge a écrit : v4 patch attached. v5 patch attached. Thanks Guillaume. Maybe this is nit-picking, but i see that you have to rmdir() an existing empty tablespace directory to use

Re: [HACKERS] Patch for ALTER DATABASE WITH TABLESPACE

--On Freitag, November 07, 2008 09:36:32 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: Bernd, did you have any further comments? If not I'll get started on this patch. No, i think this patch is ready for a committer then. -- Thanks Bernd -- Sent via pgsql-hackers mailing l

Re: [HACKERS] ALTER DATABASE SET TABLESPACE vs crash safety

--On Sonntag, November 09, 2008 18:25:50 -0600 Decibel! <[EMAIL PROTECTED]> wrote: On Nov 7, 2008, at 9:53 AM, Tom Lane wrote: FWIW, I don't see this patch as being terribly useful in the real world until it can take place in the background, without locking stuff for a huge amount of time. T

Re: [HACKERS] WIP: Automatic view update rules

--On Dienstag, November 11, 2008 23:06:08 -0500 Robert Haas <[EMAIL PROTECTED]> wrote: Thanks for your look at this. Unfortunately i was travelling the last 2 days, so i didn't have time to reply earlier, sorry for that. I haven't done a full review of this patch, but here are some thoughts

Re: [HACKERS] WIP: Automatic view update rules

--On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas <[EMAIL PROTECTED]> wrote: Do you intend to submit an updated version of this patch for this commitfest? I'll do asap, i've updated the status to 'waiting on author'. -- Thanks Bernd -- Sent via pgsql-hackers m

Re: [HACKERS] patch: Add columns via CREATE OR REPLACE VIEW

--On Donnerstag, August 07, 2008 08:03:52 -0400 Robert Haas <[EMAIL PROTECTED]> wrote: Here's a patch that allows CREATE OR REPLACE VIEW to add new columns to an existing view. Any feedback would be appreciated, especially if it meant that I could fix any problems before the next commitfest.

Re: [HACKERS] WIP: Automatic view update rules

--On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle wrote: --On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas wrote: Do you intend to submit an updated version of this patch for this commitfest? I'll do asap, i've updated the status to 'waiting on author

Re: [HACKERS] WIP: Automatic view update rules

> On Mon, Dec 22, 2008 at 8:53 AM, Bernd Helmle > wrote: >> --On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle >> wrote: >> >> Okay, i've finally managed to create an updated version with (hopefully) >> all >> issues mentioned by Robert ad

Re: [HACKERS] WIP: Automatic view update rules

> On Sun, Dec 28, 2008 at 9:29 AM, Bernd Helmle wrote: > > i would say check for negative attnums and deny that view to be > updateable because of SQL92 says in 11.19 syntax > rule 6: > """ > 6) If the is updatable, then the viewed table &

Re: [HACKERS] Time to finalize patches for 8.4 beta

--On Montag, Januar 05, 2009 17:12:27 -0800 Josh Berkus 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 (pgsql-hackers@postgr

Re: [HACKERS] WIP: Automatic view update rules

--On Sonntag, Dezember 28, 2008 15:29:58 +0100 Bernd Helmle 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 columns (extract

Re: [HACKERS] WIP: Automatic view update rules

--On Freitag, Januar 09, 2009 13:20:57 +0100 Bernd Helmle 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 in a current

Re: [HACKERS] WIP: Automatic view update rules

--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle 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 and so the new

Re: [HACKERS] WIP: Automatic view update rules

--On Montag, Januar 12, 2009 14:48:46 +0200 Peter Eisentraut 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 viewUpdate.o view

Re: FWD: Re: [HACKERS] Updated backslash consistency patch

--On Donnerstag, Januar 15, 2009 17:51:35 +0200 Peter Eisentraut 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 this? I'd lik

Re: [HACKERS] WIP: Automatic view update rules

--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut 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 was that it wou

Re: [HACKERS] WIP: Automatic view update rules

--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut 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. checkTree() will r

Re: [HACKERS] pg_get_viewdef formattiing

--On Donnerstag, Januar 22, 2009 15:30:35 -0500 Andrew Dunstan 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 me. -- Thanks

Re: [HACKERS] Build system problem in 8.3.x

--On 27. August 2009 11:34:29 +0200 Boszormenyi Zoltan 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 -Wdeclaration-after-state

Re: [HACKERS] Hot Standby 0.2.1

--On 15. September 2009 22:41:59 +0100 Simon Riggs 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 ? -- Thanks B

Re: [HACKERS] [patch] pg_ctl init extension

--On 17. September 2009 23:00:12 +0300 Peter Eisentraut 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 "" to push down command line

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 25. August 2009 22:17:38 -0400 Alvaro Herrera 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 pg_roles need a join to obt

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 20. September 2009 22:56:53 -0400 Robert Haas 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 the weekend, i'm sorry).

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 21. September 2009 13:42:21 +0200 Bernd Helmle wrote: --On 20. September 2009 22:56:53 -0400 Robert Haas 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 tom

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 23. September 2009 14:10:39 -0400 Tom Lane 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 "pg_user_setting"

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 27. September 2009 21:59:37 -0400 Robert Haas 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 pg_db_role_setting.h, it doesn't compil

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 28. September 2009 19:02:34 -0400 Alvaro Herrera 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 until Thursday. -- Thanks

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 30. September 2009 13:19:53 -0400 Alvaro Herrera 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 is. Some additional not

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 1. Oktober 2009 17:22:06 -0400 Alvaro Herrera 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 version. -- Thanks Be

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 1. Oktober 2009 17:22:06 -0400 Alvaro Herrera 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 role/database in two concurrent

Re: [HACKERS] Rules: A Modest Proposal

--On 5. Oktober 2009 09:51:29 +0300 Peter Eisentraut 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 of "substitution

Re: [HACKERS] Rules: A Modest Proposal

--On 4. Oktober 2009 21:37:45 -0400 Robert Haas 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: http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php Bu

Re: [HACKERS] Patch: create or replace language

--On 6. Oktober 2009 10:13:54 -0400 Tom Lane 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 keep an eye on ALTER

Re: [HACKERS] Going, going, GUCs!

--On 20. Oktober 2009 10:49:33 -0700 David Fetter 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 update_process_title

[HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

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 foo2(another_i

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

--On 4. November 2009 09:57:27 -0500 Tom Lane 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. Ah okay, should hav

Re: [HACKERS] Listen / Notify rewrite

--On 12. November 2009 15:48:44 + Greg Stark 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 solution you have in

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

--On 4. November 2009 09:57:27 -0500 Tom Lane 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. I've just started

Re: [HACKERS] EOL for 7.4?

--On 12. November 2009 15:23:06 -0500 Andrew Dunstan wrote: What I and others have been arguing is necessary to do EOL right is a serious amount of notice, by way of press releases etc. We can't expect users to keep polling our web site to see if there's an EOL. That means we need to prepar

Re: [HACKERS] ALTER ROLE/DATABASE RESET ALL versus security

--On 13. November 2009 19:08:22 -0500 Tom Lane 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 security hole? I woul

[HACKERS] DTrace compiler warnings

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 (e.g

Re: [HACKERS] patch - per-tablespace random_page_cost/seq_page_cost

--On 14. November 2009 20:22:42 -0500 Robert Haas wrote: I will take another crack at it. ...Robert I take this that you are going to provide a new patch version? -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subs

Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

--On 16. November 2009 11:00:33 -0700 Alex Hunsaker wrote: Anyway Bernd if you are working on this great! If not lemme know, Ill plan on having something for the next commit feast. Though I still may never get around to it :(. I'm just working on it. The current patch assigns __not_nul

[HACKERS] Strange behavior with leap dates and centuries BC

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

Re: [HACKERS] Strange behavior with leap dates and centuries 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 throu

Re: [HACKERS] Strange behavior with leap dates and centuries BC

--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 interpre

Re: [HACKERS] [PATCHES] Updatable views

--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 up

[HACKERS] Re: Separate psql commands from arguments (was: psql command aliases support)

--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: On Fri, Apr 4, 2008 at 4:19 AM, To

[HACKERS] Re: Separate psql commands from arguments (was: psql command aliases support)

--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

Re: [HACKERS] Separate psql commands from arguments

--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 happe

Re: [HACKERS] Separate psql commands from arguments

--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

[HACKERS] CommitFest Wiki page annoyance

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 care

Re: [HACKERS] CommitFest Wiki page annoyance

--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 defin

[HACKERS] Adding variables for segment_size, wal_segment_size and block sizes

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 segme

Re: [HACKERS] A Windows x64 port of MySQL

--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 ann

Re: [HACKERS] Adding variables for segment_size, wal_segment_size and block sizes

--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

Re: [HACKERS] log_rotation_age integer overflow display quirk

--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): test

[HACKERS] Missing descriptions for aggregates

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? --

[HACKERS] Schema-qualified statements in pg_dump output

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 [-t ]. I found it a common use case to restore this dump into a different schema by simply changing the s

Re: [HACKERS] Schema-qualified statements in pg_dump output

--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

Re: [HACKERS] Schema-qualified statements in pg_dump output

--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

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On 23. Januar 2009 13:28:27 -0500 Tom Lane 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 happier if such revie

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On 23. Januar 2009 17:32:55 -0500 Tom Lane wrote: Bernd Helmle writes: --On 23. Januar 2009 13:28:27 -0500 Tom Lane wrote: In short, I don't feel that this was ready to be applied. Uh well, i'd be happier if such review comments would have been made earlier in the

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On 23. Januar 2009 18:02:55 -0500 Jaime Casanova 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 regarding some discussions las

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On 23. Januar 2009 18:07:38 -0500 Jaime Casanova 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 a new DO INSTEAD rule (someth

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On 23. Januar 2009 21:18:19 -0500 Robert Haas 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 the submitter can add it

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On Samstag, Januar 24, 2009 14:17:58 -0500 Tom Lane wrote: ON UPDATE DO INSTEAD UPDATE base_table SET base_col_1 = new.derived_col_1, base_col_2 ... WHERE CURRENT OF VIEW; and the rewriter would interpret this appropriately. You'd end up with essentially the same results as with the ot

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On Sonntag, Januar 25, 2009 09:41:14 +0100 Guillaume Smet wrote: I think that we probably want the rules to show up automatically during an upgrade from an older version I'm really not convinced by that. Is it required by the standard? It's really far from being compliant with the principl

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On 24. Januar 2009 20:47:20 -0500 Tom Lane wrote: Bernd Helmle writes: What i'm missing is some notion about CHECK OPTION. We surely want to support that in way. Feel free to insist on that, if you want to make dead certain that updatable views don't make it into 8.4 ;-)

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On 25. Januar 2009 12:16:56 -0500 Andrew Dunstan wrote: Maybe something like CREATE VIEW WITHOUT UPDATE; I actually like the idea of being able to turn update on and off for a view. Or what about CREATE [OR REPLACE] [UPDATABLE] VIEW ... ? This looks closer to TEMP|TEMPORARY VIE

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On 25. Januar 2009 13:36:35 -0500 Tom Lane wrote: But per spec, UPDATABLE should be the default (if not now, then eventually). Are you proposing CREATE [OR REPLACE] [[NOT] UPDATABLE] VIEW ... ? Seems confusing. Good point. We need a better phrasing to restore the old behavior, m

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On Montag, Januar 26, 2009 20:03:41 -0800 Josh Berkus wrote: Jaime, Bernd, having said that, i don't think that inventing new syntax is the way to go... a reloption seems better (thinking a little more, it could be a problem if the user changes the reloptions of an already created view)

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

--On Dienstag, Januar 27, 2009 14:04:05 +0200 Peter Eisentraut wrote: a view should be updatable by default if the query expression is updatable... what we need is something to make a view READ ONLY even if it should be updatable by spec... A view is read-only if you don't grant any write pe

[HACKERS] HotStandby-Patch and WAL_DEBUG

I'm currently testing HotStandby v9g. Seems like this patch version misses to update guc.c, which still references XLOG_DEBUG when compiled with WAL_DEBUG. This got replaced with XLOG_DEBUG_FLUSH, *_BGFLUSH and *_REDO, resulting in a compile error. Maybe we want to reflect those changes with n

[HACKERS] HotStandby vs. flatfile updates

I'm currently facing with a strange behavior during HotStandby Testing. That's what i'm actually doing: MASTER: CREATE DATABASE foo; archive_timeout)> STANDBY: postgres=# SELECT oid, datname FROM pg_database; oid | datname ---+--- 1 | template1 11561 | template0 11562 |

Re: [HACKERS] HotStandby vs. flatfile updates

--On Mittwoch, Februar 11, 2009 19:27:51 + Simon Riggs wrote: I did publish v9h to Hackers on 27 Jan, but did not put a new version onto the Wiki at that time. Sorry Bernd. Great! I just thought its worth reporting it. Sorry for the noise and missing the new patch version. I am havi

Re: [HACKERS] temporarily stop autovacuum

--On Mittwoch, Februar 11, 2009 13:18:11 -0500 Robert Haas wrote: In any case it's not difficult to write a script that loops over all of your tables with ALTER TABLE. It's probably not as fast as a single UPDATE statement, but I suspect you'd need to have an enormous number of tables for tha

Re: [HACKERS] The science of optimization in practical terms?

--On Donnerstag, Februar 12, 2009 16:06:31 -0800 "Joshua D. Drake" wrote: However, in recent times I have found that increasing cpu_tuple_cost, cpu_operator_cost and cpu_index_tuple_cost to be very useful. This is always in the scenario of, "queries were running fine for months and then all of

Re: [HACKERS] Validating problem in the isn contrib module

--On Freitag, März 06, 2009 02:26:12 +0100 Andreas 'ads' Scherbaum wrote: test=# select is_valid('978-3-937514-69-6'::isbn13); ERROR: invalid check digit for ISBN number: "978-3-937514-69-6", should be 7 ROW 1: select is_valid('978-3-937514-69-6'::isbn13); According to the docs, this is int

Re: [HACKERS] Validating problem in the isn contrib module

--On Freitag, März 06, 2009 11:32:14 +0100 Andreas 'ads' Scherbaum wrote: No. Straight from the source: -- isn_weak(boolean) - Sets the weak input mode. -- This function is intended for testing use only! The validator function should use the weak mode for itself to return 'f' in case of inv

Re: [HACKERS] Should SET ROLE inherit config params?

--On Mittwoch, März 11, 2009 21:45:00 + Simon Riggs wrote: This is as documented (although I want to add a line to SET ROLE docs) but is it the behavior we want? I for one would like SET ROLE to change runtime configs. Sounds good to me, but you may want to explore what problems that mi

Re: [HACKERS] maintenance_work_mem and autovacuum

--On Donnerstag, März 26, 2009 13:43:45 -0700 Josh Berkus wrote: I actually have a client who does both automated and manual vacuums. Having two settings would definitely be convenient for them. I often found people doing this running within a) their own superuser with special GUCs set or b

[HACKERS] Error message and infinite date and timestamp conversion in XML

map_sql_value_to_xml_value() currently errors out with a more or less vague error message, when a date or timestamp datatype with an infinite value is converted to XML. This is likely to create some confusion, especially when you have to debug some complex procedures and involved XML conversio

Re: [HACKERS] Error message and infinite date and timestamp conversion in XML

--On Freitag, März 27, 2009 14:59:23 -0400 Tom Lane wrote: Should we consider doing something about that, or is it okay as-is? I'd say yes, but i don't understand why xmlelement() doesn't call map_sql_value_to_xml_value() already instead of calling the output function directly? -- Thank

Re: [HACKERS] Documentation Update: Document pg_start_backup checkpoint behavior

--On Freitag, April 03, 2009 08:30:14 +0300 Heikki Linnakangas wrote: The first looks nicer, IMHO, because the word 'lazy' makes it self-documenting. In the second form, you have to look at the manual to figure out what the 2nd argument does. Regarding that many catalog functions are already

Re: [HACKERS] planner crash/assert hit in 8.4B1

--On Sonntag, April 19, 2009 15:29:01 +0200 Stefan Kaltenbrunner wrote: Program received signal SIGSEGV, Segmentation fault. 0x082d27ef in estimate_num_groups (root=0x8566398, groupExprs=0x85b9ed8, input_rows=1159344) at selfuncs.c:3071 3071Assert(rel->reloptkind == RELOPT_

[HACKERS] bytea vs. pg_dump

From time to time we had complains about slow dump of large tables with bytea columns, people often complaining about a) size and b) duration of the dump. That latter occurred recently to me, a customer would like to dump large tables (approx. 12G in size) with pg_dump, but he was annoyed ab

Re: [HACKERS] bytea vs. pg_dump

--On Dienstag, Mai 05, 2009 10:00:37 -0400 Tom Lane wrote: Seems like the right response might be some micro-optimization effort on byteaout. Hmm looking into profiler statistics seems to second your suspicion: Normal COPY shows: % cumulative self self total time s

Re: [HACKERS] Prepared transactions vs novice DBAs, again

--On Dienstag, Mai 05, 2009 15:29:15 + Greg Sabino Mullane wrote: It simply checks the age of entries in pg_prepared_xacts and gives a warning if the number is at or over the given threshhold (defaults to 1 second). I'm still a heavy +1 on making the default Postgres configuration value 0,

Re: [HACKERS] bytea vs. pg_dump

--On Dienstag, Mai 05, 2009 16:57:50 -0400 Andrew Dunstan wrote: Hex will already provide some space savings over our current encoding method for most byteas anyway. It's not like we'd be making things less efficient space-wise. And in compressed archives the space difference is likely to diss

[HACKERS] ToDo: Clear table counters on TRUNCATE

I had a deeper look into $subject. As Tom already noted in [1], this can't be done by simply issueing a reset message to the stats collector. TRUNCATE is transactional and can be rolled back. This is becoming more problematic, if someone is using SAVEPOINTs or is going to fill a previously trunc

Re: [HACKERS] Values of fields in Rules

--On Dienstag, Mai 05, 2009 20:25:54 -0400 Alvaro Herrera wrote: Not that I know of (and yes, this sucks). But doesn't this also apply to triggers? I can't think of a reliable way to distinguish specified or unspecified fields in trigger functions as wellmaybe fiddling with DEFAULT exp

Re: [HACKERS] Some 8.4 changes needed according to pg_migrator testing

--On 7. Mai 2009 15:32:01 -0400 Tom Lane wrote: I think the part that goes "en_US" or whatever is actually quite well standardized (except for good ol' Windows, but we could provide a mapping from the Unix-style names to Windows names). I like this idea, but i could imagine that this is pre

Re: [HACKERS] bytea vs. pg_dump

--On Mittwoch, Mai 06, 2009 19:04:21 -0400 Tom Lane wrote: So I'm now persuaded that a better textual representation for bytea should indeed make things noticeably better here. It would be useful though to cross-check this thought by profiling a case that dumps a comparable volume of text dat

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

--On 11. Mai 2009 06:38:44 -0300 Lucas Brito wrote: Why not extend the "SET" instruction to allow configuration parameters to be set only in the duration of the transaction or the next "n" commands? It's already there: see SET LOCAL. -- Thanks Bernd -- Sent via pgsql-hackers mail

Re: [HACKERS] bytea vs. pg_dump

--On Mittwoch, Mai 06, 2009 19:04:21 -0400 Tom Lane wrote: So I'm now persuaded that a better textual representation for bytea should indeed make things noticeably better here. It would be useful though to cross-check this thought by profiling a case that dumps a comparable volume of text dat

Re: [HACKERS] bytea vs. pg_dump

--On Samstag, Mai 30, 2009 00:47:16 +0300 Hannu Krosing wrote: And we can also escape the need to uncompress TOAST'ed fields - just markup the compression as another \c at the beginning of data. Hmm i thought about that, but that seems only to make sense if there is an easy way to "bypass"

<    1   2   3   4   5   >