On Sun, Dec 26, 2010 at 08:13:40PM -0500, Tom Lane wrote:
[ thinks for a bit... ] One reason for having a different structure
would be if we needed to represent abstract semantics for some operators
that couldn't be associated with a btree opclass. This is clearly not
an issue for what RANGE
On 28.12.2010 05:16, Robert Haas wrote:
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haasrobertmh...@gmail.com wrote:
In fact, basically all you can do with CREATE FOREIGN TABLE is set column
names, types, and whether they're NOT NULL. But I think that's enough
to get started.
Even NOT NULL
On 28.12.2010 05:16, Robert Haas wrote:
I'd appreciate some review of what's attached, even though it's not
totally final yet.
This construct doesn't translate well:
+ appendStringInfo(allowed, table%s%s%s,
+ allowView ? or view : ,
+
On Tue, Dec 28, 2010 at 18:45, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
In fact, basically all you can do with CREATE FOREIGN TABLE is set column
names, types, and whether they're NOT NULL. But I think that's enough
to get started.
Even NOT NULL seems questionable. It
On 26/12/10 21:33, Jan Urbański wrote:
On 26/12/10 21:17, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
Makes sense. Wait, no, errcodes.sgml includes the entries for success
and warnings, but the plpgsql conditions list does not. So we need a
separate column to
On Tue, Dec 28, 2010 at 1:52 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
On Mon, 27 Dec 2010 22:16:42 -0500
Robert Haas robertmh...@gmail.com wrote:
OK, here's the patch. Changes from the submitted fdw_syntax patch:
In psql document, I found an inconsistency between \command-letter
On Tue, Dec 28, 2010 at 4:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.12.2010 05:16, Robert Haas wrote:
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haasrobertmh...@gmail.com
wrote:
In fact, basically all you can do with CREATE FOREIGN TABLE is set column
names,
On Tue, Dec 28, 2010 at 4:59 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 28.12.2010 05:16, Robert Haas wrote:
I'd appreciate some review of what's attached, even though it's not
totally final yet.
This construct doesn't translate well:
Yeah, there are a bunch of
On Tue, Dec 28, 2010 at 1:39 AM, Josh Berkus j...@agliodbs.com wrote:
While I don't want to discourage you from working on steam-based
estimators ... I'd love to see you implement a proof-of-concept for
PostgreSQL, and test it ... the above is a non-argument. It requires us
to accept that
On Tue, Dec 28, 2010 at 12:45 AM, David Fetter da...@fetter.org wrote:
I don't see how people can be relying on links to 9.1-to-be's
documentation.
Well, it's always handy when the filenames are the same across
versions. Ever looked at the 9.0 documentation for something and then
modified the
n Mon, Dec 27, 2010 at 1:23 PM, Joel Jacobson j...@gluefinance.com wrote:
I'm working on a tool to simplify updating the source code of database
functions.
To do a revert my plan is to store the values of pg_proc.* before
updating, and then to restore pg_proc for the given oid if a revert is
Part of this may be my C skills not being good enough - if so, please
enlighten me :-)
My pg_streamrecv no longer works with 9.1, because it returns
PGRES_COPY_BOTH instead of PGRES_COPY_OUT when initating a copy.
That's fine.
So I'd like to make it work on both. Specifically, I would like it
On Tue, Dec 28, 2010 at 7:13 AM, Magnus Hagander mag...@hagander.net wrote:
Part of this may be my C skills not being good enough - if so, please
enlighten me :-)
My pg_streamrecv no longer works with 9.1, because it returns
PGRES_COPY_BOTH instead of PGRES_COPY_OUT when initating a copy.
On Tue, Dec 28, 2010 at 13:18, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 28, 2010 at 7:13 AM, Magnus Hagander mag...@hagander.net wrote:
Part of this may be my C skills not being good enough - if so, please
enlighten me :-)
My pg_streamrecv no longer works with 9.1, because it
On Tue, Jun 22, 2010 at 06:18, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Magnus Hagander mag...@hagander.net wrote:
The downside is that version 1 will require an initdb, and not version
2, right?
Unfortunately, 2 also requires initdb because pg_stat_activity will
use LEFT
Currently, a number of functions return data in a really
calculation-unfriendly format, e.g:
postgres=# select * from pg_current_xlog_location();
pg_current_xlog_location
--
0/3013158
(1 row)
It would be very useful to have a way to convert this to a bigint - so
we can
On Tue, Dec 28, 2010 at 21:46, Magnus Hagander mag...@hagander.net wrote:
Unfortunately, 2 also requires initdb because pg_stat_activity will
use LEFT JOIN instead of normal JOIN not to hide rows with databaseid = 0.
All of them are items for 9.1.
Did this one end up on the floor?
We
Excerpts from David Fetter's message of mar dic 28 02:45:11 -0300 2010:
On Tue, Dec 28, 2010 at 03:49:16AM +, Peter Geoghegan wrote:
Attached documentation patch should make things clearer. I haven't
changed the queries-with section to
queries-common-table-expression per David's
On Tue, Dec 28, 2010 at 14:14, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Dec 28, 2010 at 21:46, Magnus Hagander mag...@hagander.net wrote:
Unfortunately, 2 also requires initdb because pg_stat_activity will
use LEFT JOIN instead of normal JOIN not to hide rows with databaseid =
2010/12/28 Robert Haas robertmh...@gmail.com
I'm not immediately sure whether it's safe, but it seems like playing
with fire, and I don't see any particular advantage to doing it this
way over using CREATE OR REPLACE FUNCTION.
While I understand some of the SQL commands affecting pg_catalog
On 28.12.2010 15:19, Joel Jacobson wrote:
2010/12/28 Robert Haasrobertmh...@gmail.com
I'm not immediately sure whether it's safe, but it seems like playing
with fire, and I don't see any particular advantage to doing it this
way over using CREATE OR REPLACE FUNCTION.
While I understand some
Attached patch implements a function called pg_primary_conninfo() that
returns, well, the primary_conninfo used on the standby when in
streaming replication mode (otherwise NULL).
Objections?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
***
On Tue, Dec 28, 2010 at 8:19 AM, Joel Jacobson j...@gluefinance.com wrote:
My plan:
1. Take snapshot of pg_catalog.pg_proc.*
2. Update existing/install new source code of functions
3. Monitor how the live system behaves (might take 30 minutes or something
like that)
4. If problems occurr,
On Tue, Dec 28, 2010 at 8:31 AM, Magnus Hagander mag...@hagander.net wrote:
Attached patch implements a function called pg_primary_conninfo() that
returns, well, the primary_conninfo used on the standby when in
streaming replication mode (otherwise NULL).
+1. Let's make sure to explicitly
On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander mag...@hagander.net wrote:
Currently, a number of functions return data in a really
calculation-unfriendly format, e.g:
postgres=# select * from pg_current_xlog_location();
pg_current_xlog_location
--
0/3013158
(1
On Tue, Dec 28, 2010 at 14:38, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 28, 2010 at 8:31 AM, Magnus Hagander mag...@hagander.net wrote:
Attached patch implements a function called pg_primary_conninfo() that
returns, well, the primary_conninfo used on the standby when in
streaming
The simple truth is
1) sampling-based estimators are a dead-end
The Charikar and Chaudhuri paper does not, in fact, say that it is
impossible to improve sampling-based estimators as you claim it does. In
fact, the authors offer several ways to improve sampling-based
estimators. Further,
On Tue, Dec 28, 2010 at 14:39, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander mag...@hagander.net wrote:
Currently, a number of functions return data in a really
calculation-unfriendly format, e.g:
postgres=# select * from pg_current_xlog_location();
Excerpts from Magnus Hagander's message of mar dic 28 10:46:31 -0300 2010:
On Tue, Dec 28, 2010 at 14:39, Robert Haas robertmh...@gmail.com wrote:
What's the best way of doing it? Should we have a function that takes
text as input, or should the functions in question be made to return a
On 28 December 2010 12:09, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 28, 2010 at 12:45 AM, David Fetter da...@fetter.org wrote:
I don't see how people can be relying on links to 9.1-to-be's
documentation.
Well, it's always handy when the filenames are the same across
versions.
Hi,
Please see the following plan:
postgres=# explain select * from small_table left outer join big_table using
(id);
QUERY PLAN
Hash Left Join (cost=126408.00..142436.98 rows=371
On tis, 2010-12-28 at 00:19 +, Peter Geoghegan wrote:
It's worth noting that officially (i.e. in the docs), we don't even
call CTEs CTEs at any point. We call them WITH queries. I think that
that's a mistake because we call them CTEs everywhere else.
I think WITH query or WITH clause is
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 28, 2010 at 7:13 AM, Magnus Hagander mag...@hagander.net wrote:
Also, I notice that PGRES_COPY_BOTH was inserted in the middle of
the enum. Doesn't that mean we can get incorrect values for e.g.
PGRES_FATAL_ERROR if the client is built
t...@fuzzy.cz wrote:
So even with 10% of the table, there's a 10% probability to get an
estimate that's 7x overestimated or underestimated. With lower
probability the interval is much wider.
Hmmm... Currently I generally feel I'm doing OK when the estimated
rows for a step are in the right
Peter Eisentraut pete...@gmx.net writes:
On tis, 2010-12-28 at 00:19 +, Peter Geoghegan wrote:
It's worth noting that officially (i.e. in the docs), we don't even
call CTEs CTEs at any point. We call them WITH queries. I think that
that's a mistake because we call them CTEs everywhere
Magnus Hagander mag...@hagander.net writes:
Attached patch implements a function called pg_primary_conninfo() that
returns, well, the primary_conninfo used on the standby when in
streaming replication mode (otherwise NULL).
Objections?
What's the use case? And aren't there security reasons
On Dec 28, 2010 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Attached patch implements a function called pg_primary_conninfo() that
returns, well, the primary_conninfo used on the standby when in
streaming replication mode (otherwise NULL).
I know its been discussed before, and one big problem is license and
patent problems.
Would this project be a problem:
http://oldhome.schmorp.de/marc/liblzf.html
-Andy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Dec 28, 2010 at 5:13 AM, Jie Li jay23j...@gmail.com wrote:
Hi,
Please see the following plan:
postgres=# explain select * from small_table left outer join big_table
using (id);
QUERY PLAN
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 28, 2010 at 13:18, Robert Haas robertmh...@gmail.com wrote:
Adding a #define to our headers that you can test for seems like the way to
go.
That's kind of what I was going for ;)
I don't see the point. You're going to need a *run
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Magnus Hagander's message of mar dic 28 10:46:31 -0300 2010:
Well, yeah, that was obvious ;) The question is, how much do we prefer
the more elegant method? ;)
If we go the new type route, do we need it to have an implicit cast
On Tue, Dec 28, 2010 at 10:10 AM, Andy Colson a...@squeakycode.net wrote:
I know its been discussed before, and one big problem is license and patent
problems.
Would this project be a problem:
http://oldhome.schmorp.de/marc/liblzf.html
It looks like even liblzf is not going to be accepted.
Magnus Hagander mag...@hagander.net writes:
On Dec 28, 2010 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What's the use case? And aren't there security reasons to NOT expose
that? It might contain a password for instance.
Good point - should be made superuser only.
I'm still wondering
On Dec 28, 2010, at 10:33 AM, Joachim Wieland j...@mcknight.de wrote:
On Tue, Dec 28, 2010 at 10:10 AM, Andy Colson a...@squeakycode.net wrote:
I know its been discussed before, and one big problem is license and patent
problems.
Would this project be a problem:
t...@fuzzy.cz wrote:
So even with 10% of the table, there's a 10% probability to get an
estimate that's 7x overestimated or underestimated. With lower
probability the interval is much wider.
Hmmm... Currently I generally feel I'm doing OK when the estimated
rows for a step are in the
Dear fellow hackers,
Problem: A normal diff of two slightly different schema dump files (pg_dump
-s), will not produce a user-friendly diff, as you get all changes in the
same file.
Solution: I propose a new option to pg_dump, --split, which dumps each
object to a separate file in a user
On 28 December 2010 14:53, Tom Lane t...@sss.pgh.pa.us wrote:
I'm with Peter on that. CTE is a completely meaningless term to most
users.
I don't believe that that's the case. If CTE is a completely
meaningless term to most users, WITH query is even more meaningless. I
never refer to WITH
Martijn van Oosterhout klep...@svana.org writes:
On Sun, Dec 26, 2010 at 08:13:40PM -0500, Tom Lane wrote:
[ thinks for a bit... ] One reason for having a different structure
would be if we needed to represent abstract semantics for some operators
that couldn't be associated with a btree
Joel Jacobson j...@gluefinance.com writes:
Dear fellow hackers,
Problem: A normal diff of two slightly different schema dump files (pg_dump
-s), will not produce a user-friendly diff, as you get all changes in the
same file.
Solution: I propose a new option to pg_dump, --split, which dumps
Le 28/12/2010 16:34, Tom Lane a écrit :
Magnus Hagander mag...@hagander.net writes:
On Dec 28, 2010 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What's the use case? And aren't there security reasons to NOT expose
that? It might contain a password for instance.
Good point - should be made
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2010 16:34, Tom Lane a écrit :
I'm still wondering what's the actual use-case for exposing this inside
SQL. Those with a legitimate need-to-know can look at the slave
server's config files, no?
This is something I wanted to have in
2010/12/28 Tom Lane t...@sss.pgh.pa.us
Joel Jacobson j...@gluefinance.com writes:
Dear fellow hackers,
Problem: A normal diff of two slightly different schema dump files
(pg_dump
-s), will not produce a user-friendly diff, as you get all changes in the
same file.
Solution: I propose
Le 28/12/2010 17:36, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2010 16:34, Tom Lane a écrit :
I'm still wondering what's the actual use-case for exposing this inside
SQL. Those with a legitimate need-to-know can look at the slave
server's config files, no?
On Tue, Dec 28, 2010 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I can see the point of, say, a primary_host_address() function returning
inet, which would be way better on both those dimensions than the
current proposal. But I'm not sure what else would be needed.
+1, since it
Joel Jacobson j...@gluefinance.com writes:
2010/12/28 Tom Lane t...@sss.pgh.pa.us
Joel Jacobson j...@gluefinance.com writes:
Solution: I propose a new option to pg_dump, --split, which dumps each
object to a separate file in a user friendly directory structure:
Um ... how does that solve
2010/12/28 Tom Lane t...@sss.pgh.pa.us
That has at least as many failure modes as the other representation.
I don't follow, what do you mean with failure modes? The oid in the
filename? I suggested to use a sequence instead but you didn't comment on
that. Are there any other failure modes
Le 28/12/2010 17:50, Gurjeet Singh a écrit :
On Tue, Dec 28, 2010 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I can see the point of, say, a primary_host_address() function returning
inet, which would be way better on both those dimensions than the
current proposal. But I'm not sure
I've applied all of this, and written documentation for all of it,
Thank you a lot
except for the contrib/btree_gist additions which still need to be
redone for the revised API (and then documented!). My patience ran out
Done, btree_gist is reworked for a new API.
I'm very sorry, but I'm
Excerpts from Karl Lehenbauer's message of mar dic 28 12:33:42 -0300 2010:
Project name: Add table function support to PL/Tcl (Todo item)
What the patch does:
This patch adds table function support (returning record and SETOF record)
to PL/Tcl. This patch also updates PL/Tcl to use the
On 12/28/2010 11:59 AM, Joel Jacobson wrote:
2010/12/28 Tom Lane t...@sss.pgh.pa.us mailto:t...@sss.pgh.pa.us
That has at least as many failure modes as the other representation.
I don't follow, what do you mean with failure modes? The oid in the
filename? I suggested to use a
On Tue, Dec 28, 2010 at 04:35:26PM +0200, Peter Eisentraut wrote:
On tis, 2010-12-28 at 00:19 +, Peter Geoghegan wrote:
It's worth noting that officially (i.e. in the docs), we don't even
call CTEs CTEs at any point. We call them WITH queries. I think that
that's a mistake because we
Joel Jacobson j...@gluefinance.com writes:
2010/12/28 Tom Lane t...@sss.pgh.pa.us
That has at least as many failure modes as the other representation.
I don't follow, what do you mean with failure modes? The oid in the
filename? I suggested to use a sequence instead but you didn't comment on
On Tue, Dec 28, 2010 at 11:00 AM, Joel Jacobson j...@gluefinance.comwrote:
Dear fellow hackers,
Problem: A normal diff of two slightly different schema dump files (pg_dump
-s), will not produce a user-friendly diff, as you get all changes in the
same file.
Solution: I propose a new option
On Tue, Dec 28, 2010 at 11:59 AM, Joel Jacobson j...@gluefinance.com wrote:
I don't follow, what do you mean with failure modes? The oid in the
filename? I suggested to use a sequence instead but you didn't comment on
that. Are there any other failure modes which could cause a diff -r between
On Dec 28, 2010, at 10:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm still wondering what's the actual use-case for exposing this inside
SQL. Those with a legitimate need-to-know can look at the slave
server's config files, no?
SQL access is frequently more convenient, though. Although maybe
Le 28/12/2010 18:12, Robert Haas a écrit :
On Dec 28, 2010, at 10:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm still wondering what's the actual use-case for exposing this inside
SQL. Those with a legitimate need-to-know can look at the slave
server's config files, no?
SQL access is
On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Dec 28, 2010, at 10:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm still wondering what's the actual use-case for exposing this inside
SQL. Those with a legitimate need-to-know can look at the slave
server's
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
While I am working on pg_ctl, I saw this TODO item:
Have the postmaster write a random number to a file on startup that
pg_ctl checks against the contents of a pg_ping response on its initial
connection (without login)
Gurjeet Singh singh.gurj...@gmail.com writes:
On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas robertmh...@gmail.com wrote:
SQL access is frequently more convenient, though. Although maybe now that
we've made recovery.conf use the GUC lexer we oughta continue in that vein
and expose those
flyusa2010 fly wrote:
Hi, folks,
in src/template/darwin:
# Select appropriate semaphore support. Darwin 6.0 (Mac OS X 10.2) and up
# support System V semaphores; before that we have to use POSIX semaphores,
# which are less good for our purposes because they eat a file descriptor
# per
Le 28/12/2010 19:30, Tom Lane a écrit :
Gurjeet Singh singh.gurj...@gmail.com writes:
On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas robertmh...@gmail.com wrote:
SQL access is frequently more convenient, though. Although maybe now that
we've made recovery.conf use the GUC lexer we oughta
On Tue, Dec 28, 2010 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh singh.gurj...@gmail.com writes:
On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas robertmh...@gmail.com
wrote:
SQL access is frequently more convenient, though. Although maybe now
that
we've made recovery.conf
Is there an overview of SLRU anywhere? I've looked over the code
enough to know that it'll save me a day or two if I can get an
overview of correct usage, rather than to reverse engineer it from
source code. There is no README with useful information, and
searches of the Wiki and the docs have
2010/12/28 Gurjeet Singh singh.gurj...@gmail.com
I would suggest the directory structure as:
/crypt/pg.dump-split/schema-name-1/VIEWS/view-name-1.sql
/crypt/pg.dump-split/schema-name-1/TABLES/table-name-1.sql
...
/crypt/pg.dump-split/schema-name-2/VIEWS/view-name-1.sql
On tis, 2010-12-28 at 16:04 +, Peter Geoghegan wrote:
If I search for common table expressions on Wikipedia, I am sent to
the common table expressions article, without any re-direction. The
article doesn't mention with query as a synonym of CTE at any point.
If I search for With query, the
On tis, 2010-12-28 at 09:31 -0800, David Fetter wrote:
Common Table Expression, or CTE for short, is the standard
terminology, and I don't just mean SQL:2008. It's standard in DB2,
Drizzle, Firebird, HSQLDB, Informix, Microsoft SQL Server, Oracle, and
Sybase SQL Anywhere, at a minimum.
Bruce Momjian br...@momjian.us writes:
flyusa2010 fly wrote:
in src/template/darwin:
# Select appropriate semaphore support. Darwin 6.0 (Mac OS X 10.2) and up
# support System V semaphores; before that we have to use POSIX semaphores,
# which are less good for our purposes because they eat
On Tue, Dec 28, 2010 at 2:39 PM, Joel Jacobson j...@gluefinance.com wrote:
2010/12/28 Gurjeet Singh singh.gurj...@gmail.com
I would suggest the directory structure as:
/crypt/pg.dump-split/schema-name-1/VIEWS/view-name-1.sql
/crypt/pg.dump-split/schema-name-1/TABLES/table-name-1.sql
...
Alpha3 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
If there are no concerns, I will move them to the FTP site tomorrow
(Wednesday) and send out announcements on Thursday.
--
Sent via pgsql-hackers mailing list
Sent from my iPhone
On 28 dec 2010, at 21:45, Gurjeet Singh singh.gurj...@gmail.com wrote:
The problem I see with suffixing a sequence id to the objects with name
collision is that one day the dump may name myfunc(int) as myfunc.sql and
after an overloaded version is created, say myfunc(char,
Hmm, I ran the code through pgindent so I don't understand why there are
whitespace changes.
OK I'll see what the problem is with the whitespace and instead produce two
patches, one that converts to using Tcl objects and one on top of that that
adds returning records and setof records.
On Dec
On 12/28/2010 04:44 PM, Joel Jacobson wrote:
The problem I see with suffixing a sequence id to the objects with
name collision is that one day the dump may name myfunc(int) as
myfunc.sql and after an overloaded version is created, say
myfunc(char, int), then the same myfunc(int) may be
I'm now deep enough into the SLRU techniques to see what my options
are for storing the data appropriate for SLRU. This consists of
uint64 commitSeqNo (which is overkill enough that I'd be comfortable
stealing a bit or two from the high end in SLRU usage) which needs
to be associated with an xid.
2010/12/28 Andrew Dunstan and...@dunslane.net
I think that's just horrible. Does the i stand for integer or inet? And it
will get *really* ugly for type names with spaces in them ...
True, true.
But while c is too short, I think character varying is too long. Is
there some convenient lookup
I've been fooling around with creating upgrade-in-place support for the
Fedora/RHEL RPMs. What I want to have is a separate postgresql-upgrade
RPM containing just the minimum possible set of previous-release files,
together with pg_upgrade itself. Experimenting with this convinced me
that
Andrew Dunstan and...@dunslane.net writes:
On 12/28/2010 04:44 PM, Joel Jacobson wrote:
Perhaps abbreviations are to prefer, e.g., myfunc_i, myfunc_i_c, etc
to reduce the need of truncating filenames.
I think that's just horrible. Does the i stand for integer or inet? And
it will get
On Tue, Dec 28, 2010 at 4:57 PM, Andrew Dunstan and...@dunslane.net wrote:
On 12/28/2010 04:44 PM, Joel Jacobson wrote:
The problem I see with suffixing a sequence id to the objects with name
collision is that one day the dump may name myfunc(int) as myfunc.sql and
after an overloaded
On Tue, Dec 28, 2010 at 2:39 PM, Joel Jacobson j...@gluefinance.com wrote:
I think you are right about functions (and aggregates) being the only
desc-type where two objects can share the same name in the same schema.
This means the problem of dumping objects in different order is a very
On 28 December 2010 20:07, Peter Eisentraut pete...@gmx.net wrote:
The phrase common table expression does not appear anywhere in the SQL
standard. The standard uses the grammar symbol with clause.
I think we're losing sight of the issue a bit here.
No one is proposing that we call WITH
2010/12/29 David Wilson david.t.wil...@gmail.com
Why not place all overloads of a function within the same file? Then,
assuming you order them deterministically within that file, we sidestep the
file naming issue and maintain useful diff capabilities, since a diff of the
function's file will
On 29.12.2010 00:10, Kevin Grittner wrote:
(2) Use 8 byte SLRU entries and map the xid values over the SLRU
space, with each spot allowing two different xid values. At first
blush that looks good, because transaction ID wrap-around techniques
mean that the two values for any one spot couldn't
David Wilson david.t.wil...@gmail.com writes:
On Tue, Dec 28, 2010 at 2:39 PM, Joel Jacobson j...@gluefinance.com wrote:
I didn't include the arguments in the file name, as it would lead to very
long file names unless truncated, and since the problem is very limited, I
think we shouldn't
Karl Lehenbauer karllehenba...@gmail.com writes:
The first patch, pltcl-karl-try2-1-of-3-pgindent.patch, does nothing but
conform HEAD's pltcl.c with pgindent. Applying this patch should have
exactly the same effect as running
src/tools/pgindent/pgindent
2010/12/29 Tom Lane t...@sss.pgh.pa.us
If you've solved the deterministic-ordering problem, then this entire
patch is quite useless. You can just run a normal dump and diff it.
No, that's only half true.
Diff will do a good job minimizing the size of the diff output, yes, but
such a diff
On 12/28/2010 08:18 PM, Joel Jacobson wrote:
2010/12/29 Tom Lane t...@sss.pgh.pa.us mailto:t...@sss.pgh.pa.us
If you've solved the deterministic-ordering problem, then this entire
patch is quite useless. You can just run a normal dump and diff it.
No, that's only half true.
Diff
On Mon, Dec 27, 2010 at 2:06 PM, Robert Haas robertmh...@gmail.com wrote:
The problem is that alter table actions AT_AddIndex and
AT_AddConstraint don't tie neatly back to a particular piece of
syntax. The message as written isn't incomprehensible (especially if
you're reading it in English)
2010/12/29 Andrew Dunstan and...@dunslane.net
try:
diff -F '^CREATE' ...
cheers
andrew
Embarrasing, I'm sure I've done `man diff` before, must have missed that
one, wish I'd known about that feature before, would have saved me many
hours! :-) Thanks for the tip!
There are some other
97 matches
Mail list logo
