Re: [HACKERS] search_path improvements WAS: search_path vs extensions

On May 29, 2009, at 5:16 PM, Greg Stark wrote: On Fri, May 29, 2009 at 11:03 PM, David E. Wheeler > wrote: On May 29, 2009, at 2:52 PM, Josh Berkus wrote: a) the ability to "push" a schema onto the current search path b) the ability to "pull" a schema off the current search path push, pop, s

[HACKERS] dot to be considered as a word delimiter?

Currently it seems like that dot is not considered as a word delimiter by the english parser. lawdb=# select to_tsvector('english', 'Mr.J.Sai Deepak'); to_tsvector - 'deepak':2 'mr.j.sai':1 (1 row) So the word obtained is "mr.j.sai" rather than three words "

Re: [HACKERS] Allow vacuumdb to only analyze

On May 27, 2009, at 11:31 AM, decibel wrote: It does seem somewhat useful to be able to analyze all databases easily from the command-line, but putting it into vacuumdb is certainly a hack. So... do we want a completely separate analyzedb command? That seems like far overkill. Arguably there

[HACKERS] explan refactoring

As I was trying to figure out the least invasive way to make explain_outNode() support machine-readable output, I noticed that there is a whole pile of duplicated code for dealing with scan targets. The attached refactoring may be worth applying independently of what happens with the rest of the p

Re: [HACKERS] libpq is not thread safe

Zdenek Kotala wrote: > > Bruce Momjian p??e v ?t 28. 05. 2009 v 17:20 -0400: > > > > > > > Done, patch attached and applied. > > > > I went with a because it seemed most appropriate, but it looks > > very large: > > > > http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html >

Re: [HACKERS] search_path vs extensions

On Fri, May 29, 2009 at 7:53 PM, Greg Stark wrote: > On Fri, May 29, 2009 at 11:18 PM, Robert Haas wrote: >> >> Good point.  But maybe there's some way of getting some kind of >> behavior that is closer to lexical scoping/early binding?  Because the >> way it works right now has lousy security im

Re: [HACKERS] search_path improvements WAS: search_path vs extensions

On Fri, May 29, 2009 at 10:52 PM, Josh Berkus wrote: > Sometimes one needs to use schemas just for namespacing (they are called > "namespaces" after all), and not for security or visibility. What's the point of "namespaces" if not to implement visibility? The interesting thing to do would be to

Re: [HACKERS] search_path improvements WAS: search_path vs extensions

On Fri, May 29, 2009 at 11:03 PM, David E. Wheeler wrote: > On May 29, 2009, at 2:52 PM, Josh Berkus wrote: > >> a) the ability to "push" a schema onto the current search path >> b) the ability to "pull" a schema off the current search path > > push, pop, shift, unshift. :-) > > Come to think of i

Re: [HACKERS] search_path vs extensions

On Fri, May 29, 2009 at 11:18 PM, Robert Haas wrote: > > Good point.  But maybe there's some way of getting some kind of > behavior that is closer to lexical scoping/early binding?  Because the > way it works right now has lousy security implications, beyond being > difficult for search_path manag

Re: [HACKERS] Python 3.0 does not work with PL/Python

On May 29, 2009, at 1:17 AM, Peter Eisentraut wrote: On Friday 29 May 2009 04:06:14 Andrew Dunstan wrote: Otherwise, I'm not too keen simply to throw Python 2.x overboard until it's no longer common on platforms people are likely to want to install Postgres on, if that's what's implied by th

Re: [HACKERS] information_schema.columns changes needed for OLEDB

Tom, this is very helpful - thank you so much! I had to discover those 'missing' functions one by one, usually after users' complaints. Konstantin On Fri, May 29, 2009 at 11:35 AM, Tom Lane wrote: > Konstantin Izmailov writes: > > you know that some Postgres functions are listed in pg_proc wh

Re: [HACKERS] search_path vs extensions

On Fri, 29 May 2009, Greg Stark wrote: The only reason people are having trouble managing their search_path is because they're not using it as intended and putting things in lots of different schemas that they intend to all be visible. If they put everything they intend to be visible to users

Re: [HACKERS] search_path vs extensions

On Fri, May 29, 2009 at 5:45 PM, Greg Stark wrote: > On Fri, May 29, 2009 at 10:26 PM, Robert Haas wrote: >> This sounds quite horrid to me.  The way programming languages solve >> this problem is they have a flag that either makes certain names not >> visible from other namespaces, or they provi

Re: [HACKERS] Testing of parallel restore with current snapshot

Tom, Here's a draft patch that does ordering using two lists, as I proposed. Please test to see if it's any faster or slower than the original logic. Great. I'll need to get permission from a client; I can't host large enough/complex enough databases on my own system. :-( -- Josh Berkus P

Re: [HACKERS] search_path improvements WAS: search_path vs extensions

On May 29, 2009, at 2:52 PM, Josh Berkus wrote: a) the ability to "push" a schema onto the current search path b) the ability to "pull" a schema off the current search path push, pop, shift, unshift. :-) Come to think of it, I want these for arrays, too. ;-) Best, David -- Sent via pgsql-h

Re: [HACKERS] search_path vs extensions

On May 29, 2009, at 2:45 PM, Greg Stark wrote: 2) Normally programming languages do early binding so as soon as the code is parsed references are resolved. You can't later define a new function earlier in the search path and have it take over references that have were previously referring to som

Re: [HACKERS] search_path vs extensions

On May 29, 2009, at 12:41 PM, Greg Stark wrote: That said, I don't mind the idea of having a way to push things onto search path like you often do in sh using PATH=/foo/bar:$PATH. Yes, +1. But I think the only reason to install something into a separate schema is precisely if you *want* that

Re: [HACKERS] search_path vs extensions

Robert, Of course we have no notion of exporting or importing names at all. Maybe we should. But I'm still of the opinion that this entire discussion is a tangent. As far as Extensions are concerned? Yes, it is. Dimitri: I vote for you to get on with assuming everything goes into pg_exten

Re: [HACKERS] search_path improvements WAS: search_path vs extensions

Greg, Do we really? The only reason people are having trouble managing their search_path is because they're not using it as intended and putting things in lots of different schemas that they intend to all be visible. Apparently you've never adminned a database with hundreds (or thousands) of

Re: [HACKERS] bytea vs. pg_dump

On Fri, 2009-05-29 at 11:06 +0300, Peter Eisentraut wrote: > On Friday 29 May 2009 04:26:35 Bruce Momjian wrote: > > Added to TODO: > > |Improve bytea COPY format > > > > * http://archives.postgresql.org/pgsql-hackers/2009-05/msg00192.php > > Btw., I have started to write some code for tha

Re: [HACKERS] bytea vs. pg_dump

On Wed, 2009-05-06 at 18:33 +0300, Peter Eisentraut wrote: > On Tuesday 05 May 2009 17:38:33 Tom Lane wrote: > > "Kevin Grittner" writes: > > > Bernd Helmle wrote: > > >> Another approach would be to just dump bytea columns in binary > > >> format only (not sure how doable that is, though). > > >

Re: [HACKERS] search_path vs extensions

On Fri, May 29, 2009 at 10:26 PM, Robert Haas wrote: > This sounds quite horrid to me.  The way programming languages solve > this problem is they have a flag that either makes certain names not > visible from other namespaces, or they provide explicit control over > which names get exported. The

Re: [HACKERS] information_schema.columns changes needed for OLEDB

Konstantin Izmailov writes: > you know that some Postgres functions are listed in pg_proc while others are > not. For example, all Data Type Formatting function are in pg_proc (to_char, > to_hex, ...). While several of the Date/Time Functions are not there > (extract, localtime, ...). The ones th

Re: [HACKERS] Testing of parallel restore with current snapshot

Josh Berkus writes: > Tom, >> Is anyone interested enough to try it if I code it? > If you're patient for results, sure. I seem to be doing a customer > migration or upgrade every week now, so it wouldn't take me long to have > a test subject with a fairly complex database. Here's a draft pat

Re: [HACKERS] search_path vs extensions

On Fri, May 29, 2009 at 4:49 PM, Tom Lane wrote: > Greg Stark writes: >> I'm actually not sure if we should allow extensions to be installed >> into separate schemas. > > It's starting to seem that best practice is to install "public" > functions/etc into a common schema and "private" objects int

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Fri, 2009-05-29 at 11:12 +0300, Peter Eisentraut wrote: > On Friday 29 May 2009 03:53:17 Alvaro Herrera wrote: > > Bruce Momjian escribió: > > > Peter Eisentraut wrote: > > > > On Monday 06 April 2009 02:10:59 James Pye wrote: > > > > > Any thoughts on the acceptability of a complete rewrite for

Re: [HACKERS] search_path vs extensions

Tom Lane wrote: Greg Stark writes: I'm actually not sure if we should allow extensions to be installed into separate schemas. It's starting to seem that best practice is to install "public" functions/etc into a common schema and "private" objects into an extension-specific schema.

Re: [HACKERS] search_path vs extensions

Greg Stark writes: > I'm actually not sure if we should allow extensions to be installed > into separate schemas. It's starting to seem that best practice is to install "public" functions/etc into a common schema and "private" objects into an extension-specific schema. The main problem with that

Re: [HACKERS] Clean shutdown and warm standby

On Fri, 2009-05-29 at 14:54 -0400, Robert Haas wrote: > On Fri, May 29, 2009 at 2:23 PM, Simon Riggs wrote: > > Regrettably, the patch doesn't remove the problem it was supposed to > > remove and I'm highlighting there is still risk of data loss. I suggest > > that we don't change any docs, and c

Re: [HACKERS] search_path vs extensions

On Fri, May 29, 2009 at 5:23 PM, David E. Wheeler wrote: >> PS: we still have to provide users with easy tools to (dynamically) manage >> search_path, don't we? >> (I prefer not to start the search_path management tool ideas right here). > > Yes, we do, and that's what at least half this thread is

Re: [HACKERS] Clean shutdown and warm standby

On Fri, 2009-05-29 at 21:46 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > Regrettably, the patch doesn't remove the problem it was supposed to > > remove and I'm highlighting there is still risk of data loss. > > I feel that you're moving the goalposts. What exactly is the problem it

Re: [HACKERS] pg_migrator and an 8.3-compatible tsvector data type

Tom Lane wrote: > Josh Berkus writes: > > It would be nice to have pg_migrator handle this, especially if we could > > do it in parallel. Then we just have to warn users that migrating a > > database with tsvector columns takes significantly longer. That is, > > > 1) do rest of catalog swap a

Re: [HACKERS] Clean shutdown and warm standby

On Fri, May 29, 2009 at 2:23 PM, Simon Riggs wrote: > Regrettably, the patch doesn't remove the problem it was supposed to > remove and I'm highlighting there is still risk of data loss. I suggest > that we don't change any docs, and carefully word or even avoid any > release note inclusion to avo

Re: [HACKERS] explain analyze rows=%.0f

On Fri, May 29, 2009 at 1:30 PM, Tom Lane wrote: > Joshua Tolley writes: >> On Thu, May 28, 2009 at 11:12:42PM -0400, Robert Haas wrote: >>> On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira Don't you think is too strange having, for example, 6.67 rows? >>> >>> No stranger than hav

Re: [HACKERS] Clean shutdown and warm standby

Simon Riggs wrote: Regrettably, the patch doesn't remove the problem it was supposed to remove and I'm highlighting there is still risk of data loss. I feel that you're moving the goalposts. What exactly is the problem it was supposed to remove in your opinion? -- Heikki Linnakangas Ent

Re: [HACKERS] pg_migrator and an 8.3-compatible tsvector data type

Josh Berkus writes: > It would be nice to have pg_migrator handle this, especially if we could > do it in parallel. Then we just have to warn users that migrating a > database with tsvector columns takes significantly longer. That is, > 1) do rest of catalog swap and link/copy of objects. > 2

Re: [HACKERS] pg_migrator and an 8.3-compatible tsvector data type

Bruce, So, one idea would be, instead of a cast, have pg_migrator rebuild the tsvector columns with ALTER TABLE, so then the 8.4 index code could be used. But then we might as well just tell the users to migrate the tsvector tables themselves, which is how pg_migrator behaves now. It would be

Re: [HACKERS] Clean shutdown and warm standby

On Thu, 2009-05-28 at 18:09 -0400, Tom Lane wrote: > What's your point? Surely the applied patch is a *necessary* component > of any attempt to try to ensure archiving is complete at shutdown. > I agree that it doesn't cover every risk factor, and there are some > risk factors that cannot be cove

Re: [HACKERS] [GENERAL] trouble with to_char('L')

Hiroshi Inoue writes: > Tom Lane wrote: >> I think what this suggests is that there probably needs to be some >> encoding conversion logic near the places we examine localeconv() >> output. > Attached is a patch to the current CVS. > It uses a similar way like LC_TIME stuff does. I'm not really

Re: [HACKERS] pg_migrator and an 8.3-compatible tsvector data type

Tom Lane wrote: > Josh Berkus writes: > > Bruce, > >> The ordering of the lexems was changed: > > > What does that get us in terms of performance etc.? > > It was changed to support partial-match tsvector queries. Without it, > a partial match query would have to scan entire tsvectors instead >

Re: [HACKERS] information_schema.columns changes needed for OLEDB

Hi, I'm not sure that it is related to information_schema but I wanted to let you know that some Postgres functions are listed in pg_proc while others are not. For example, all Data Type Formatting function are in pg_proc (to_char, to_hex, ...). While several of the Date/Time Functions are not ther

Re: [HACKERS] search_path vs extensions

Dimitri, We'd still need search_path in there, as Python's still using a path. With 'default' search_path you'd have to qualify your type as pg_extensions.postgis.submodule.special_type, with pg_extensions in search_path the following notation would find it too: postgis.submodule.special_type. A

Re: [HACKERS] explain analyze rows=%.0f

Joshua Tolley writes: > On Thu, May 28, 2009 at 11:12:42PM -0400, Robert Haas wrote: >> On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira >>> Don't you think is too strange having, for example, 6.67 rows? >> >> No stranger than having it say 7 when it's really not. Actually mine >> mos

Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP

On May 29, 11:48 am, Kevin Field wrote: > On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote: > > > > > On Fri, May 29, 2009 at 7:59 AM, Kevin Field > > wrote: > > > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote: > > >> On May 28, 2009, at 12:53 PM, Kevin Field

Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP

Kevin Field writes: > default: > elog(ERROR, "unrecognized raise option: %d", > opt->opt_type); > Should this be changed to: > default: > ereport(ERROR, (errmsg_internal("unrecognized > raise option: %d", > opt->opt_type))); No, we g

Re: [HACKERS] PostgreSQL Developer meeting minutes up

* Alvaro Herrera [090529 11:45]: > Aidan Van Dyk wrote: > > > Yes, but the point is you want an exact replica of CVS right? You're > > git repo should have $PostgreSQL$ and the cvs export/checkout (you do > > use -kk right) should also have $PostgreSQL$. > > > > The 3 parsecvs errors were that

Re: [HACKERS] PostgreSQL Developer meeting minutes up

Tom Lane escribió: > Alvaro Herrera writes: > > Tom Lane escribi�: > >> What was in the back of my mind was that we'd go around and mass-remove > >> $PostgreSQL$ (and any other lurking tags), but only from HEAD and only > >> after the repo conversion. Although just before it would be okay too. >

Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP

On May 29, 11:48 am, Kevin Field wrote: > On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote: > > > > > On Fri, May 29, 2009 at 7:59 AM, Kevin Field > > wrote: > > > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote: > > >> On May 28, 2009, at 12:53 PM, Kevin Field

Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP

On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote: > On Fri, May 29, 2009 at 7:59 AM, Kevin Field > wrote: > > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote: > >> On May 28, 2009, at 12:53 PM, Kevin Field wrote: > > >> >> Can pgTap check for a regex instead if j

Re: [HACKERS] search_path vs extensions

On May 29, 2009, at 3:38 AM, Dimitri Fontaine wrote: PS: we still have to provide users with easy tools to (dynamically) manage search_path, don't we? (I prefer not to start the search_path management tool ideas right here). Yes, we do, and that's what at least half this thread is about.

Re: [HACKERS] search_path vs extensions

On May 29, 2009, at 3:24 AM, Peter Eisentraut wrote: Yeah, to reiterate what I posted elsewhere, perhaps it'd be a good idea to give up on the search path idea altogether and think more in terms of an import facility like Python, Java, and sometimes Perl have. +1 Actually, Perl's is usual

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Zdenek Kotala writes: > Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400: >> The proposed signature change on psql_completion >> is going to replace a warning on your system with outright failures on >> other people's. > I check readline and definition is still same at least from 5.0 version. > I

Re: [HACKERS] search_path vs extensions

Le 29 mai 09 à 17:12, Tom Lane a écrit : What it sounds like to me is an amazingly complicated gadget with absolutely no precedent of successful use anywhere. We'll spend a year fooling with the details of this and be no closer to actually solving the problem at hand, namely getting a simple

Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP

On May 29, 2009, at 4:59 AM, Kevin Field wrote: http://github.com/theory/pgtap/tree/master/ I'm getting a new version ready to release as I type. Thanks, great to know. :) Although, I do think changing plperl is the more proper option, so I'm going to try there first... I added `throws_

Re: [HACKERS] PostgreSQL Developer meeting minutes up

Aidan Van Dyk wrote: > Yes, but the point is you want an exact replica of CVS right? You're > git repo should have $PostgreSQL$ and the cvs export/checkout (you do > use -kk right) should also have $PostgreSQL$. > > The 3 parsecvs errors were that it *didn't* recognoze the strange > $PostgreSQL

Re: [HACKERS] Python 3.0 does not work with PL/Python

Andrew Dunstan writes: > David Blewett wrote: >> I brought this up last August [1]. Zope has a working sandbox that >> they include in their distribution. >> http://archives.postgresql.org/message-id/9d1f8d830808041008v50104fd8p6181d5ddce85...@mail.gmail.com >> > How many python installations

Re: [HACKERS] pg_migrator and an 8.3-compatible tsvector data type

Tom Lane píše v pá 29. 05. 2009 v 11:28 -0400: > Zdenek Kotala writes: > > The biggest problem is dictionary change. I'm not sure if it happened > > but IIRC Teodor mentioned it in Ottawa. If it happened It hits down > > tsvector compatibility at all. > > No more than changing dictionary behav

Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP

Kevin Field wrote: On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote: On May 28, 2009, at 12:53 PM, Kevin Field wrote: Can pgTap check for a regex instead if just a string? That's the other option, if the pgTAP author is willing...if the SQLSTATE thing doe

Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP

On Fri, May 29, 2009 at 7:59 AM, Kevin Field wrote: > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote: >> On May 28, 2009, at 12:53 PM, Kevin Field wrote: >> >> >> Can pgTap check for a regex instead if just a string? >> >> > That's the other option, if the pgTAP author is will

Re: [HACKERS] PostgreSQL Developer meeting minutes up

* Markus Wanner [090529 11:18]: > Hi, > > Quoting "Aidan Van Dyk" : >> * Markus Wanner [090529 11:06]: >>> Comparison of the head of each branch between git and CVS (modulo CVS >>> keyword expansion, which I've filtered out): >> >> How did you filter it out > > With perl some regexes. > >> and wi

Re: [HACKERS] search_path vs extensions

Tom Lane wrote: Dimitri Fontaine writes: Le 29 mai 09 à 16:11, Andrew Dunstan a écrit : I think almost all these difficulties could be overcome if we had some sort of aliasing support, so that arbitrary objects in schema a could be aliased in schema b. If that were in place, best

Re: [HACKERS] pg_migrator and an 8.3-compatible tsvector data type

Zdenek Kotala writes: > The biggest problem is dictionary change. I'm not sure if it happened > but IIRC Teodor mentioned it in Ottawa. If it happened It hits down > tsvector compatibility at all. No more than changing dictionary behavior in an existing installation. What was stated when the is

Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP

On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote: > On May 28, 2009, at 12:53 PM, Kevin Field wrote: > > >> Can pgTap check for a regex instead if just a string? > > > That's the other option, if the pgTAP author is willing...if the > > SQLSTATE thing doesn't work out I guess we'

Re: [HACKERS] PostgreSQL Developer meeting minutes up

Hi, Quoting "Aidan Van Dyk" : * Markus Wanner [090529 11:06]: Comparison of the head of each branch between git and CVS (modulo CVS keyword expansion, which I've filtered out): How did you filter it out With perl some regexes. and without the filtering out, how does it do? Uh.. why is

Re: [HACKERS] search_path vs extensions

Dimitri Fontaine writes: > Le 29 mai 09 à 16:11, Andrew Dunstan a écrit : >> I think almost all these difficulties could be overcome if we had >> some sort of aliasing support, so that arbitrary objects in schema a >> could be aliased in schema b. If that were in place, best practice >> wou

Re: [HACKERS] PostgreSQL Developer meeting minutes up

* Markus Wanner [090529 11:06]: > Hi, > Comparison of the head of each branch between git and CVS (modulo CVS > keyword expansion, which I've filtered out): How did you filter it out, and without the filtering out, how does it do? > I plan to compare the tags as well and test what branch they

Re: [HACKERS] PostgreSQL Developer meeting minutes up

Hi, Quoting "Aidan Van Dyk" : Ok, so seeing the interest in having a "good conversion", I took a stab at parsecvs this afternoon, probably what I consider the leading "static" conversion tool. Here are some results from a conversion with cvs2git. It takes about 10 minutes to run my old xeon.

Re: [HACKERS] search_path vs extensions

Hi, Le 29 mai 09 à 16:11, Andrew Dunstan a écrit : I think almost all these difficulties could be overcome if we had some sort of aliasing support, so that arbitrary objects in schema a could be aliased in schema b. If that were in place, best practice would undoubtedly be for each module

Re: [HACKERS] Python 3.0 does not work with PL/Python

David Blewett wrote: On Thu, May 28, 2009 at 9:06 PM, Andrew Dunstan > wrote: Does Python 3 have some sort of usable sandbox that would mean we could have a trusted plpython? I brought this up last August [1]. Zope has a working sandbox that they include

Re: [HACKERS] pg_migrator and an 8.3-compatible tsvector data type

Alvaro Herrera writes: > Bruce Momjian wrote: >> Alvaro Herrera wrote: >>> Why not? Right now it's single-threaded. Would it be faster if it ran >>> several copies in parallel? >> >> Sure, but that assumes you have parallel I/O channels; I assume right >> now it is I/O limited. > But so does

Re: [HACKERS] search_path vs extensions

Peter Eisentraut wrote: On Thursday 28 May 2009 02:57:00 Josh Berkus wrote: Personally, if we're tracking stuff through special dependancies which pg_dump will be aware of anyway, I don't see why extension objects should go into a special schema. But they clearly have to go into *som

Re: [HACKERS] Warnings in compile

On Mon, May 25, 2009 at 12:10:49PM -0400, Tom Lane wrote: > [ thinks for a bit... ] What might be both safe and warning-free > is to code an explicit empty statement, viz macro body as > > if (1) { ... } else ((void) 0) I just tried this and yes, it quietens gcc and probably is at least as

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On Fri, May 29, 2009 at 2:41 AM, Markus Wanner wrot> Hi, > Quoting "Robert Haas" : >> Why is this harder than I think it is? > > One of the simplest possible example is something like: Thanks for the explanation, I understand it better now. I'm still dismayed, but at least I know why I'm dismaye

Re: [HACKERS] pg_migrator and an 8.3-compatible tsvector data type

Bruce Momjian píše v čt 28. 05. 2009 v 17:42 -0400: > Josh Berkus wrote: > > On 5/28/09 2:30 PM, Bruce Momjian wrote: > > > Because no one has responded, I am going to prevent pg_migrator from > > > working with a cluster that uses tsvector. I realize this limits > > > pg_migrator's usefulness, b

Re: [HACKERS] pg_migrator and an 8.3-compatible tsvector data type

Alvaro Herrera wrote: Bruce Momjian wrote: Alvaro Herrera wrote: There are so many caveats on pg_migrator (and things that need to be done after the migration is complete) that one starts to wonder if people is not better off just using parallel pg_restore. From Stefan's reported timings I'm

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Tom Lane píše v čt 28. 05. 2009 v 11:57 -0400: > ). > > AFAICS, Sun's compiler is just too stupid and shouldn't be emitting > this warning. Perhaps the right response is to file a bug report > against the compiler. I checked it and it is already know bug. It is new lint style check in Sun Studi

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400: > Zdenek Kotala writes: > > I attached another cleanup patch which fixes following warnings reported > > by Sun Studio: > > I'm not too impressed with any of these. The proposed added > initializers just increase future maintenance effort without s

Re: [HACKERS] libpq is not thread safe

Bruce Momjian píše v čt 28. 05. 2009 v 17:20 -0400: > > > > Done, patch attached and applied. > > I went with a because it seemed most appropriate, but it looks > very large: > > http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html > > Should it be a notice? I prefer war

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Thu, May 28, 2009 at 9:06 PM, Andrew Dunstan wrote: > Does Python 3 have some sort of usable sandbox that would mean we could > have a trusted plpython? I brought this up last August [1]. Zope has a working sandbox that they include in their distribution. David Blewett 1. http://archives.p

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Thu, May 28, 2009 at 09:06:14PM -0400, Andrew Dunstan wrote: > Does Python 3 have some sort of usable sandbox that would mean we could > have a trusted plpython? Not sure if people are aware of object-capability based approaches to security. A guy called Tav has come up with some code that co

Re: [HACKERS] search_path vs extensions

Hi, Le 29 mai 09 à 12:18, Peter Eisentraut a écrit : I think what this comes down to is that you need nested schemas and a global namespace rule. Then you can install things into pg_extensions.postgis.submodule.special_type, etc. Makes sense on paper. [...] (One such new insight might be

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On Thursday 28 May 2009 20:03:38 Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Right. Shall we try to spec out exactly what our conversion > > requirements are? Here's a shot: > > [...] > > > Comments? Other considerations? > > Certainly sounds reasonable to me. I'd be reall

Re: [HACKERS] search_path vs extensions

On Thursday 28 May 2009 21:38:29 Tom Lane wrote: > Greg Stark writes: > > I don't understand what storing them in different namespaces and then > > putting them all in your search_path accomplishes. You end up with the > > same mishmash of things in your namespace. > > +1 ... naming conflicts betw

Re: [HACKERS] search_path vs extensions

On Thursday 28 May 2009 15:24:21 Stephen Frost wrote: > I'm not real happy with it either. Sure, we can track module > dependencies seperately, but if we go down this route then we have to > come up with some concept of an extension namespace that different > extension use and prefix their functio

Re: [HACKERS] search_path vs extensions

On Thursday 28 May 2009 02:57:00 Josh Berkus wrote: > Personally, if we're tracking stuff through special dependancies which > pg_dump will be aware of anyway, I don't see why extension objects > should go into a special schema. But they clearly have to go into *some* schema, and it would add some

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Friday 29 May 2009 04:06:14 Andrew Dunstan wrote: > Otherwise, I'm not too keen simply to throw Python 2.x overboard until > it's no longer common on platforms people are likely to want to install > Postgres on, if that's what's implied by the original question. My guess is that we will need to

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Friday 29 May 2009 03:53:17 Alvaro Herrera wrote: > Bruce Momjian escribió: > > Peter Eisentraut wrote: > > > On Monday 06 April 2009 02:10:59 James Pye wrote: > > > > Any thoughts on the acceptability of a complete rewrite for Python 3? > > > > > > http://www.joelonsoftware.com/articles/fog

Re: [HACKERS] bytea vs. pg_dump

On Friday 29 May 2009 04:26:35 Bruce Momjian wrote: > Added to TODO: > |Improve bytea COPY format > > * http://archives.postgresql.org/pgsql-hackers/2009-05/msg00192.php Btw., I have started to write some code for that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] search_path vs extensions

Hi, Le 29 mai 09 à 02:32, Robert Haas a écrit : On Thu, May 28, 2009 at 3:32 PM, Andrew Dunstan wrote: Tom Lane wrote: Robert Haas writes: It also seems to me that we're getting seriously sidetracked from the dependency-tracking part of this project which seems to me to be a much deeper