Re: [HACKERS] Encoding issues in console and eventlog on win32

Magnus Hagander wrote: > First of all, the change to port/open.c seems to be unrelated to the > rest, and should be a separate patch, correct? I'm sure there's a > usecase for it, but it's not actually included in the patches > description, so I assume this was a mistake? It was just a demo fo

Re: [HACKERS] COPY enhancements

I just realized that I forgot to CC the list when I answered to Josh... resending! Josh, >> I think that this was the original idea but we should probably rollback >> the error logging if the command has been rolled back. It might be more >> consistent to use the same hi_options as the copy c

Re: [HACKERS] [PATCH] DefaultACLs

Tom Lane wrote: > Petr Jelinek writes: >> KaiGai Kohei napsal(a): >>> SELECT INTO does not check ACL_INSERT on the newly created tables, because >>> we had been able to assume the table owner always has privilege to insert >>> values into the new table. >>> So, OpenIntoRel() didn't check this obvi

Re: [HACKERS] Streaming Replication patch for CommitFest 2009-09

Hi, On Tue, Oct 6, 2009 at 10:42 PM, Alvaro Herrera wrote: > Hmm.  Without looking at the patch at all, this seems similar to how > autovacuum does things: autovac launcher signals postmaster that a > worker needs to be started.  Postmaster proceeds to fork a worker.  This > could obviously fail

Re: [HACKERS] [PATCH] Largeobject access controls

Tom Lane wrote: > KaiGai Kohei writes: >> I rebased the largeobject access controls patch to the CVS HEAD >> because of the patch confliction to the default ACL patch. > > Quick comment on this --- I think that using a syscache for large > objects is probably not a good idea. There is no provisi

Re: [HACKERS] Making hash indexes worthwhile

On Mon, Oct 5, 2009 at 6:49 AM, Tom Lane wrote: > Jeff Janes writes: >> Do you know why that should be?  I've done some work with gprof, and >> the results are pretty suspect, because the total gprof time adds up >> to only about 1/3 of the total time the backend spends on CPU >> (according to "t

Re: [HACKERS] Triggers on columns

On Sun, 2009-10-04 at 22:07 -0400, Tom Lane wrote: > In short: while I haven't looked at the patch, I think Peter may be > steering you in the wrong direction. > > In cases where you do have related functions, I suggest having > SQL-callable V1 functions that absorb their arguments in this > style

Re: [HACKERS] doc/src/sgml/Makefile versus VPATH

On Tue, 2009-10-06 at 12:24 -0400, Tom Lane wrote: > So isn't this still pretty broken? I notice that the clean and > distclean targets still use addprefix on a lot of temporary/intermediate > files that I would think get made in the build directory, not the source > directory. Yeah, those rules

[HACKERS] contrib/plantuner - enable PostgreSQL planner hints

Hi there, this is an announcement of our new contribution module for PostgreSQL - Plantuner - enable planner hints (http://www.sai.msu.su/~megera/wiki/plantuner). Example: =# LOAD 'plantuner'; =# create table test(id int); =# create index id_idx on test(id); =# create index id_idx2 on test(id

Re: [HACKERS] doc/src/sgml/Makefile versus VPATH

On Tue, 2009-10-06 at 12:56 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > By Peter's recent decree that tarballs are supposed to be built in > > non-vpath-builds only, I am not really sure what should actually happen > > here, both on build and on the various clean targets. > > I think that

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

On Tue, Oct 06, 2009 at 10:44:27AM +0100, Roger Leigh wrote: > On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote: > > Roger Leigh writes: > > > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote: > > >> Elsewhere in the psql code, notably in mbprint.c, we make the decision > >

Re: [HACKERS] [PATCH] Largeobject access controls

Alvaro Herrera wrote: KaiGai Kohei escribió: I added a syscache entry for pg_largeobject_metadata, not pg_largeobject which contains data chunks. The pg_largeobject_metadata is a smaller catalog than most of system catalogs, such as pg_class. The point is not the size of the cache entries, 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] doc/src/sgml/Makefile versus VPATH

Alvaro Herrera writes: > By Peter's recent decree that tarballs are supposed to be built in > non-vpath-builds only, I am not really sure what should actually happen > here, both on build and on the various clean targets. I think that that means the Makefile can just assume that *every* built fil

Re: [HACKERS] [PATCH] Largeobject access controls

KaiGai Kohei escribió: > I added a syscache entry for pg_largeobject_metadata, not pg_largeobject > which contains data chunks. The pg_largeobject_metadata is a smaller catalog > than most of system catalogs, such as pg_class. The point is not the size of the cache entries, but the number of them

Re: [HACKERS] doc/src/sgml/Makefile versus VPATH

Tom Lane wrote: > So isn't this still pretty broken? I notice that the clean and > distclean targets still use addprefix on a lot of temporary/intermediate > files that I would think get made in the build directory, not the source > directory. Yeah, I noticed that too. I'm not too sure about it,

Re: [HACKERS] [PATCH] Largeobject access controls

Tom Lane wrote: > KaiGai Kohei writes: >> I rebased the largeobject access controls patch to the CVS HEAD >> because of the patch confliction to the default ACL patch. > > Quick comment on this --- I think that using a syscache for large > objects is probably not a good idea. There is no provisi

[HACKERS] doc/src/sgml/Makefile versus VPATH

So isn't this still pretty broken? I notice that the clean and distclean targets still use addprefix on a lot of temporary/intermediate files that I would think get made in the build directory, not the source directory. The references to man files in srcdir in nonsql_manpage_files and adjacent ma

Re: [HACKERS] [PATCH] Largeobject access controls

KaiGai Kohei writes: > I rebased the largeobject access controls patch to the CVS HEAD > because of the patch confliction to the default ACL patch. Quick comment on this --- I think that using a syscache for large objects is probably not a good idea. There is no provision in the catcache code fo

Re: [HACKERS] moving system catalogs to another tablespace

Hi all, On Tue, 2009-10-06 at 16:58 +0200, Tom Lane wrote: > Yeah, I have sometimes thought that pg_largeobject shouldn't be > considered a system catalog at all. It's more nearly like a toast > table, ie, it's storing "out of line" user data. pg_largeobject in it's current form has serious limi

Re: [HACKERS] moving system catalogs to another tablespace

Jaime Casanova escreveu: > i have just read Tom's comments and yes that question was around my > mind to: a system catalog that doesn't behaves like other system > catalogs and in which we want different sets of permissions (see > kaigai san's patch about largeobject controls in which he actually a

Re: [HACKERS] moving system catalogs to another tablespace

On Tue, Oct 6, 2009 at 9:43 AM, Alvaro Herrera wrote: > Jaime Casanova wrote: > >> now i think that what Euler shows me [1] is a fair compromise (this is >> to allow this only when in standalone mode with system catalogs >> allowed) otherwise we will have diferent behaviour for specific >> (random

Re: [HACKERS] moving system catalogs to another tablespace

Alvaro Herrera writes: > I don't agree that pg_largeobject is a random catalog either -- it is, > in fact, the only catalog in which an interesting size is to be > expected. Yeah, I have sometimes thought that pg_largeobject shouldn't be considered a system catalog at all. It's more nearly like

Re: [HACKERS] Hot Standby on git

On Thu, 2009-10-01 at 18:47 +0300, Heikki Linnakangas wrote: > And if you could please review the changes I've been doing, just to > make sure I haven't inadvertently introduced new bugs. That has > happened before, as you've rightfully reminded me :-). You posted 17 patches here. I've reviewed

Re: [HACKERS] Patch: create or replace language

On Tue, Oct 6, 2009 at 10:48 AM, Tom Lane wrote: > Robert Haas writes: >> Maybe I'm out of line to say this, but it seems to me that we should >> not even be looking at newly-submitted patches at this point. > > It would have been more work to put it in the queue to reject later > than to reject

Re: [HACKERS] Patch: create or replace language

Robert Haas writes: > Maybe I'm out of line to say this, but it seems to me that we should > not even be looking at newly-submitted patches at this point. It would have been more work to put it in the queue to reject later than to reject it now ;-). Besides, this way Andreas has a chance to rewr

Re: [HACKERS] Privileges and inheritance

Tom Lane wrote: > KaiGai Kohei writes: >> Was it uncertain what I wanted to say for the proposition? > > No: it's that nobody sees any particular value in making a fundamental > restructuring of the permissions system like that. What you propose > would be far harder/more complicated to implemen

Re: [HACKERS] moving system catalogs to another tablespace

Jaime Casanova wrote: > now i think that what Euler shows me [1] is a fair compromise (this is > to allow this only when in standalone mode with system catalogs > allowed) otherwise we will have diferent behaviour for specific > (random) catalogs... > > [1] > http://listas.postgresql.org.br/pipe

Re: [HACKERS] Patch: create or replace language

Robert Haas escribió: > On Tue, Oct 6, 2009 at 10:24 AM, Alvaro Herrera > wrote: > > this comment needs fixed. > > Maybe I'm out of line to say this, but it seems to me that we should > not even be looking at newly-submitted patches at this point. Yeah, it was so short I didn't see any point in

Re: [HACKERS] [PATCH] DefaultACLs

Petr Jelinek writes: > KaiGai Kohei napsal(a): >> SELECT INTO does not check ACL_INSERT on the newly created tables, because >> we had been able to assume the table owner always has privilege to insert >> values into the new table. >> So, OpenIntoRel() didn't check this obvious privilege. >> >> B

Re: [HACKERS] Patch: create or replace language

On Tue, Oct 6, 2009 at 10:24 AM, Alvaro Herrera wrote: > Andreas 'ads' Scherbaum wrote: >> >> Hello, >> >> following this old discussion: >> >> http://archives.postgresql.org/pgsql-patches/2008-03/msg00402.php >> >> i modifies the patch to use the "CREATE [OR REPLACE] LANGUAGE" syntax. >> If the p

Re: [HACKERS] moving system catalogs to another tablespace

On Mon, Oct 5, 2009 at 10:26 PM, Tom Lane wrote: > Jaime Casanova writes: >> seems like the original idea was to forbid this in all system catalogs >> except pg_largeobject, what happen then? > > Nothing ... nobody got around to doing anything about it. > ah! well, having slept a while my thinki

Re: [HACKERS] [PATCH] DefaultACLs

Petr Jelinek escribió: > Petr Jelinek napsal(a): > >Tom Lane napsal(a): > >>Petr Jelinek writes: > >>>Tom Lane napsal(a): > One thing that seems like it's likely to be an annoyance in practice > is the need to explicitly do DROP OWNED BY to get rid of pg_defaul

Re: [HACKERS] Patch: create or replace language

Andreas 'ads' Scherbaum wrote: > > Hello, > > following this old discussion: > > http://archives.postgresql.org/pgsql-patches/2008-03/msg00402.php > > i modifies the patch to use the "CREATE [OR REPLACE] LANGUAGE" syntax. > If the patch is ok, i will add the documentation too. Please send a co

Re: [HACKERS] Patch: create or replace language

"Andreas 'ads' Scherbaum" writes: > following this old discussion: > http://archives.postgresql.org/pgsql-patches/2008-03/msg00402.php > i modifies the patch to use the "CREATE [OR REPLACE] LANGUAGE" syntax. This is not an "OR REPLACE" operation, because it doesn't replace the existing definition

Re: [HACKERS] [PATCH] DefaultACLs

Petr Jelinek wrote: > KaiGai Kohei napsal(a): >> I tried to check the default ACL behavior. >> >> It works for me fine, good, but ... >> >> postgres=> SELECT * INTO t3 FROM t1; >> SELECT >> postgres=> SELECT * FROM t3; >>a | b >> ---+- >>1 | aaa >>2 | bbb >> (2 rows) >> >

Re: [HACKERS] Privileges and inheritance

KaiGai Kohei writes: > Was it uncertain what I wanted to say for the proposition? No: it's that nobody sees any particular value in making a fundamental restructuring of the permissions system like that. What you propose would be far harder/more complicated to implement, to understand, or to use

Re: [HACKERS] Streaming Replication patch for CommitFest 2009-09

Fujii Masao escribió: > On Thu, Sep 17, 2009 at 5:08 PM, Heikki Linnakangas > wrote: > > Walreceiver is really a slave to the startup process. The startup > > process decides when it's launched, and it's the startup process that > > then waits for it to advance. But the way it's set up at the mome

Re: [HACKERS] [PATCH] DefaultACLs

Petr Jelinek napsal(a): Tom Lane napsal(a): Petr Jelinek writes: Tom Lane napsal(a): One thing that seems like it's likely to be an annoyance in practice is the need to explicitly do DROP OWNED BY to get rid of pg_default_acl entries for a role to be dropp

Re: [HACKERS] [PATCH] DefaultACLs

KaiGai Kohei napsal(a): > I tried to check the default ACL behavior. > > It works for me fine, good, but ... > > postgres=> SELECT * INTO t3 FROM t1; > SELECT > postgres=> SELECT * FROM t3; >a | b > ---+- >1 | aaa >2 | bbb > (2 rows) > > postgres=> INSERT INTO t3 VALUES

Re: [HACKERS] Encoding issues in console and eventlog on win32

2009/9/15 Itagaki Takahiro : > > Heikki Linnakangas wrote: > >> Can't we use MultiByteToWideChar() to convert directly to the required >> encoding, avoiding the double conversion? > > Here is an updated version of the patch. > I use direct conversion in pgwin32_toUTF16() if a corresponding codepag

[HACKERS] Patch: create or replace language

Hello, following this old discussion: http://archives.postgresql.org/pgsql-patches/2008-03/msg00402.php i modifies the patch to use the "CREATE [OR REPLACE] LANGUAGE" syntax. If the patch is ok, i will add the documentation too. Kind regards -- Andreas 'ads'

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote: > Roger Leigh writes: > > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote: > >> Elsewhere in the psql code, notably in mbprint.c, we make the decision > >> on whether to apply certain Unicode-aware processing based on wheth

Re: [HACKERS] Streaming Replication patch for CommitFest 2009-09

Hi, On Mon, Sep 21, 2009 at 4:51 PM, Heikki Linnakangas wrote: > I've pushed that to 'replication-orig' branch in my git > repository, attached is the same as a diff against your SR_0914.patch. The following changes about crossing a xlogid boundary seem wrong, which would break the management of

Re: [HACKERS] Privileges and inheritance

Was it uncertain what I wanted to say for the proposition? In my understanding, here are two different perspectives to handle table inheritances. The one handles the inherited definitions of child tables as a part of the child table. The current implementation uses this perspective. Thus, it chec

Re: [HACKERS] Hot Standby on git

On Sun, 2009-09-27 at 13:57 +0300, Heikki Linnakangas wrote: > Per Simon's request, for the benefit of the archive, here's all the > changes I've done on the patch since he posted the initial version for > review for this commitfest as incremental patches. This is extracted > from my git reposito

Re: [HACKERS] Hot Standby on git

On Tue, 2009-10-06 at 01:10 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > We discussed briefly your change > > 0011-Replace-per-proc-counters-of-loggable-locks-with-per.patch. > > > > I don't see how that helps at all. The objective of lock counters was to > > know if we can skip acq