2010/12/29 Andrew Dunstan
> 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 real-life use-
On Mon, Dec 27, 2010 at 2:06 PM, Robert Haas 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) but it definitely
On 12/28/2010 08:18 PM, Joel Jacobson wrote:
2010/12/29 Tom Lane 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 will do a good job
2010/12/29 Tom Lane
>
> 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 is still quit
Karl Lehenbauer 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 src/tools/pgindent/typedefs.list
> src/pl/tcl/pl
David Wilson writes:
> On Tue, Dec 28, 2010 at 2:39 PM, Joel Jacobson 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 include it. It's cleaner with just the name
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 b
2010/12/29 David Wilson
> 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 show additions or rem
On 28 December 2010 20:07, Peter Eisentraut wrote:
> The phrase "common table expression" does not appear anywhere in the SQL
> standard. The standard uses the grammar symbol .
I think we're losing sight of the issue a bit here.
No one is proposing that we call WITH queries common table
express
On Tue, Dec 28, 2010 at 2:39 PM, Joel Jacobson 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
> limited problem, onl
On Tue, Dec 28, 2010 at 4:57 PM, Andrew Dunstan 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
Andrew Dunstan 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 *really* ugly for
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 pg_upgr
2010/12/28 Andrew Dunstan
>
> 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 table to c
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.
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 d
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
Sent from my iPhone
On 28 dec 2010, at 21:45, Gurjeet Singh 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
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 (pgsql-hacker
On Tue, Dec 28, 2010 at 2:39 PM, Joel Jacobson wrote:
> 2010/12/28 Gurjeet Singh
>
>> 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-nam
Bruce Momjian 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 a file
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.
>
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 qu
2010/12/28 Gurjeet Singh
> 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
> /crypt/pg.dump-split/schema-name-2/TA
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 co
On Tue, Dec 28, 2010 at 1:30 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas
> 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
Le 28/12/2010 19:30, Tom Lane a écrit :
> Gurjeet Singh writes:
>> On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas 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 thos
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
>
Gurjeet Singh writes:
> On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas 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 parameters as PGC_INTERNAL GUCs rather than
Tom Lane wrote:
> Bruce Momjian 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)
>
>
On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas wrote:
> On Dec 28, 2010, at 10:34 AM, Tom Lane 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 f
Le 28/12/2010 18:12, Robert Haas a écrit :
> On Dec 28, 2010, at 10:34 AM, Tom Lane 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
On Dec 28, 2010, at 10:34 AM, Tom Lane 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 now that
we've
On Tue, Dec 28, 2010 at 11:59 AM, Joel Jacobson 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
> two different
On Tue, Dec 28, 2010 at 11:00 AM, Joel Jacobson wrote:
> 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, -
Joel Jacobson writes:
> 2010/12/28 Tom Lane
>> 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 fail
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
On 12/28/2010 11:59 AM, Joel Jacobson wrote:
2010/12/28 Tom Lane 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 sequence instead but yo
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 t
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 ra
Le 28/12/2010 17:50, Gurjeet Singh a écrit :
> On Tue, Dec 28, 2010 at 11:36 AM, Tom Lane 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 w
2010/12/28 Tom Lane
>
> 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 which could caus
Joel Jacobson writes:
> 2010/12/28 Tom Lane
>> Joel Jacobson 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 the claimed problem exactly?
> Because then you
On Tue, Dec 28, 2010 at 11:36 AM, Tom Lane 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 bypasses security ri
Le 28/12/2010 17:36, Tom Lane a écrit :
> Guillaume Lelarge 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
2010/12/28 Tom Lane
> Joel Jacobson 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, -
Guillaume Lelarge 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 9.0 when I coded
Le 28/12/2010 16:34, Tom Lane a écrit :
> Magnus Hagander writes:
>> On Dec 28, 2010 3:58 PM, "Tom Lane" 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
Joel Jacobson 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 each
> object to
Martijn van Oosterhout 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 opclass.
> One
On 28 December 2010 14:53, Tom Lane 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 queries in conversati
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 friendly
> 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 o
On Dec 28, 2010, at 10:33 AM, Joachim Wieland wrote:
> On Tue, Dec 28, 2010 at 10:10 AM, Andy Colson 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
Magnus Hagander writes:
> On Dec 28, 2010 3:58 PM, "Tom Lane" 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 what's the actual use-case for expo
On Tue, Dec 28, 2010 at 10:10 AM, Andy Colson 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. I have proposed
Alvaro Herrera 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 to
> text, for backwar
Magnus Hagander writes:
> On Tue, Dec 28, 2010 at 13:18, Robert Haas 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 time* test on
PQserverVersion to figure
On Tue, Dec 28, 2010 at 5:13 AM, Jie Li wrote:
> Hi,
>
> Please see the following plan:
>
> postgres=# explain select * from small_table left outer join big_table
> using (id);
> QUERY PLAN
>
>
>
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:
http://www.postg
On Dec 28, 2010 3:58 PM, "Tom Lane" wrote:
>
> Magnus Hagander 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 u
Magnus Hagander 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 to NOT expose
th
Peter Eisentraut 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 else.
> I th
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 order of m
Robert Haas writes:
> On Tue, Dec 28, 2010 at 7:13 AM, Magnus Hagander 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 against one version of libpq
>> but
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"
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 width
On 28 December 2010 12:09, Robert Haas wrote:
> On Tue, Dec 28, 2010 at 12:45 AM, David Fetter 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 documenta
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 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
> >> new datatype t
On Tue, Dec 28, 2010 at 14:39, Robert Haas wrote:
> On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander 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
>>
>
>> 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.
On Tue, Dec 28, 2010 at 14:38, Robert Haas wrote:
> On Tue, Dec 28, 2010 at 8:31 AM, Magnus Hagander 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).
On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander 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 row)
>
> It w
On Tue, Dec 28, 2010 at 8:31 AM, Magnus Hagander 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 document what this f
On Tue, Dec 28, 2010 at 8:19 AM, Joel Jacobson 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, revent to the old
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/
*** a/doc/src/sg
On 28.12.2010 15:19, Joel Jacobson wrote:
2010/12/28 Robert Haas
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 af
2010/12/28 Robert Haas
> 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 have side
effects,
On Tue, Dec 28, 2010 at 14:14, Itagaki Takahiro
wrote:
> On Tue, Dec 28, 2010 at 21:46, Magnus Hagander 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.
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 Davi
On Tue, Dec 28, 2010 at 21:46, Magnus Hagander 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 definitely need
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 d
On Tue, Jun 22, 2010 at 06:18, Takahiro Itagaki
wrote:
>
> Magnus Hagander 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 JOIN instead of normal JOIN not to hide row
On Tue, Dec 28, 2010 at 13:18, Robert Haas wrote:
> On Tue, Dec 28, 2010 at 7:13 AM, Magnus Hagander 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 o
On Tue, Dec 28, 2010 at 7:13 AM, Magnus Hagander 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.
> That's fine.
>
>
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 to
n Mon, Dec 27, 2010 at 1:23 PM, Joel Jacobson 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
> necessary.
> T
On Tue, Dec 28, 2010 at 12:45 AM, David Fetter 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 URL to see what
On Tue, Dec 28, 2010 at 1:39 AM, Josh Berkus 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 sample-based esti
On Tue, Dec 28, 2010 at 4:59 AM, Heikki Linnakangas
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 remaining error message issues.
On Tue, Dec 28, 2010 at 4:45 AM, Heikki Linnakangas
wrote:
> On 28.12.2010 05:16, Robert Haas wrote:
>> On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas
>> 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
On Tue, Dec 28, 2010 at 1:52 AM, Shigeru HANADA
wrote:
> On Mon, 27 Dec 2010 22:16:42 -0500
> Robert Haas wrote:
>> OK, here's the patch. Changes from the submitted fdw_syntax patch:
>
> In psql document, I found an inconsistency between \command-letter and
> object-type has been in the original
On 26/12/10 21:33, Jan Urbański wrote:
> On 26/12/10 21:17, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 differen
On Tue, Dec 28, 2010 at 18:45, Heikki Linnakangas
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 might be interesting for the p
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 28.12.2010 05:16, Robert Haas wrote:
On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas 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 mig
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 RA
97 matches
Mail list logo
