Hi,
Quoting Robert Haas robertmh...@gmail.com:
That's not the best news I've had today...
Sorry :-(
To me they sound complex and inconvenient. I guess I'm kind of
mystified by why we can't make this work reliably. Other than the
broken tags issue we've discussed, it seems like the only
On Friday 29 May 2009 06:31:23 Bruce Momjian wrote:
Peter Eisentraut wrote:
On Tuesday 05 May 2009 03:01:05 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 14 April 2009 21:34:51 Peter Eisentraut wrote:
I think we can handle that and the cases Tom presents by
Hi,
Le 29 mai 09 à 02:32, Robert Haas a écrit :
On Thu, May 28, 2009 at 3:32 PM, Andrew Dunstan
and...@dunslane.net wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
It also seems to me that we're getting seriously sidetracked from
the
dependency-tracking part of this
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
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/fog69.html
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
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
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
On Thursday 28 May 2009 21:38:29 Tom Lane wrote:
Greg Stark st...@enterprisedb.com 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
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 really suprised
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
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
On Thu, May 28, 2009 at 9:06 PM, Andrew Dunstan and...@dunslane.net 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.
Bruce Momjian píše v čt 28. 05. 2009 v 17:20 -0400:
Done, patch attached and applied.
I went with a warning 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
Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400:
Zdenek Kotala zdenek.kot...@sun.com 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
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 Studio
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
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, but I have
On Fri, May 29, 2009 at 2:41 AM, Markus Wanner mar...@bluegap.ch wrot Hi,
Quoting Robert Haas robertmh...@gmail.com:
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
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
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
Alvaro Herrera alvhe...@commandprompt.com 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.
David Blewett wrote:
On Thu, May 28, 2009 at 9:06 PM, Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net 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
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
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
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
* Markus Wanner mar...@bluegap.ch [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
Dimitri Fontaine dfonta...@hi-media.com 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
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
* Markus Wanner mar...@bluegap.ch [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
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'll have to
Zdenek Kotala zdenek.kot...@sun.com 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
Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com 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
* Markus Wanner mar...@bluegap.ch [090529 11:18]:
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
* Markus Wanner mar...@bluegap.ch [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
On Fri, May 29, 2009 at 7:59 AM, Kevin Field kevinjamesfi...@gmail.com 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
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
Tom Lane píše v pá 29. 05. 2009 v 11:28 -0400:
Zdenek Kotala zdenek.kot...@sun.com 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
Andrew Dunstan and...@dunslane.net 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
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 ...
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
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
Zdenek Kotala zdenek.kot...@sun.com 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
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
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.
On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
On Fri, May 29, 2009 at 7:59 AM, Kevin Field kevinjamesfi...@gmail.com
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
On May 29, 11:48 am, Kevin Field kevinjamesfi...@gmail.com wrote:
On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
On Fri, May 29, 2009 at 7:59 AM, Kevin Field kevinjamesfi...@gmail.com
wrote:
On May 28, 5:19 pm, da...@kineticode.com (David E. Wheeler) wrote:
On May
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com 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
* Alvaro Herrera alvhe...@commandprompt.com [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
Kevin Field kevinjamesfi...@gmail.com 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,
On May 29, 11:48 am, Kevin Field kevinjamesfi...@gmail.com wrote:
On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
On Fri, May 29, 2009 at 7:59 AM, Kevin Field kevinjamesfi...@gmail.com
wrote:
On May 28, 5:19 pm, da...@kineticode.com (David E. Wheeler) wrote:
On May
Joshua Tolley eggyk...@gmail.com 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
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.
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
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
Hiroshi Inoue in...@tpf.co.jp 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
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 covered
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
Josh Berkus j...@agliodbs.com 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
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
On Fri, May 29, 2009 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joshua Tolley eggyk...@gmail.com 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?
On Fri, May 29, 2009 at 2:23 PM, Simon Riggs si...@2ndquadrant.com 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
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
was
On Fri, May 29, 2009 at 5:23 PM, David E. Wheeler da...@kineticode.com 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
On Fri, 2009-05-29 at 14:54 -0400, Robert Haas wrote:
On Fri, May 29, 2009 at 2:23 PM, Simon Riggs si...@2ndquadrant.com 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
Greg Stark st...@enterprisedb.com 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
Tom Lane wrote:
Greg Stark st...@enterprisedb.com 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
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 Python 3?
On Fri, May 29, 2009 at 4:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com 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
Josh Berkus j...@agliodbs.com 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
Konstantin Izmailov pgf...@gmail.com 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, ...).
On Fri, May 29, 2009 at 10:26 PM, Robert Haas robertmh...@gmail.com 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
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 kevin.gritt...@wicourts.gov writes:
Bernd Helmle maili...@oopsware.de wrote:
Another approach would be to just dump bytea columns in binary
format only (not sure
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 that.
why
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
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
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*
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
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
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
On Fri, May 29, 2009 at 5:45 PM, Greg Stark st...@enterprisedb.com wrote:
On Fri, May 29, 2009 at 10:26 PM, Robert Haas robertmh...@gmail.com 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
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
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 t...@sss.pgh.pa.us wrote:
Konstantin Izmailov pgf...@gmail.com writes:
you know that some Postgres
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
On Fri, May 29, 2009 at 11:18 PM, Robert Haas robertmh...@gmail.com 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
On Fri, May 29, 2009 at 11:03 PM, David E. Wheeler da...@kineticode.com 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
On Fri, May 29, 2009 at 10:52 PM, Josh Berkus j...@agliodbs.com 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
On Fri, May 29, 2009 at 7:53 PM, Greg Stark st...@enterprisedb.com wrote:
On Fri, May 29, 2009 at 11:18 PM, Robert Haas robertmh...@gmail.com 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
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 warning because it seemed most appropriate, but it looks
very large:
http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html
Should
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
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
89 matches
Mail list logo
