On 14.02.2011 20:10, Kevin Grittner wrote:
Promotion of the lock granularity on the prior tuple is where we
have problems. If the two tuple versions are in separate pages then
the second UPDATE could miss the conflict. My first thought was to
fix that by requiring promotion of a predicate lock
On Tue, Feb 15, 2011 at 01:27, Robert Haas robertmh...@gmail.com wrote:
However, file_fdw is in pretty serious trouble because (1) the copy
API patch that it depends on still isn't committed and (2) it's going
to be utterly broken if we don't do something about the
client_encoding vs.
On 14.02.2011 21:49, Alvaro Herrera wrote:
Thanks to Noah Misch's review of the keylock patch I noticed that
pageinspect's heap_page_items(bytea) function returns infomask and
infomask2 as smallint (signed). But the fields in the tuple header are
16 bits unsigned, so if the high (16th) bit is
- Original message -
On mån, 2011-02-14 at 22:22 +0100, Jan Urbański wrote:
The problem is that every *second* call to the function fails,
regardless of the number. The first execution succeeds, but then
PLy_delete_args deletes the argument from the globals, and when the
next
On Tue, Feb 15, 2011 at 6:12 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
from what I can see upstream libedit actually has utf8 support for a while
now (as well as some other fixes) but the debian libedit version (and also
the one of other distributions) is way too old for that so
On Tue, Feb 15, 2011 at 3:31 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Feb 15, 2011 at 01:27, Robert Haas robertmh...@gmail.com wrote:
However, file_fdw is in pretty serious trouble because (1) the copy
API patch that it depends on still isn't committed and (2) it's going
On Tue, Feb 15, 2011 at 4:31 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
array_flatten() no longer exists. I added array_trim() as an alias
to trim_array() because it would be a FAQ.
I don't like the alias thing - let's add one name or the other, not both.
Similarly, let's NOT add
On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao masao.fu...@gmail.com wrote:
You suggest that the shared variable Stream tracks the WAL write location,
after it's set to the replication starting position? I don't think
that the write
location needs to be tracked in the shmem because other
On Tue, Feb 15, 2011 at 12:46 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Feb 14, 2011 at 23:30, Stephen Frost sfr...@snowman.net wrote:
* In assign_csvlog_fields(), we need to cleanup memory and memory context
before return on error.
Fixed this and a couple of similar
On Fri, Feb 11, 2011 at 6:20 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I wrote:
Patch attached.
This time with src/backend/utils/misc/postgresql.conf.sample fixed.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
* Robert Haas (robertmh...@gmail.com) wrote:
The payoff
(getting %U) seems quite out of proportion to the potential downsides
of making a change of this type at this late date.
I'd be happy to go back to the original patch/idea of just the simple
addition of %U as an option for
On 11.02.2011 22:44, Gurjeet Singh wrote:
Looks like the function get_actual_variable_range() was written with the
knowledge that virtual/hypothetical indexes may exist, but the assumption
seems wrong.
One one hand get_actual_variable_range() expects that virtual indexes do not
have an OID
Noah,
* Noah Misch (n...@leadboat.com) wrote:
On Mon, Feb 14, 2011 at 04:06:59PM -0500, Stephen Frost wrote:
I've attached a new version of the patch that attempts to flesh out the
comments
based on your feedback. Does it improve things?
Yes, much better, thanks!
Offhand, I can't think
* Fujii Masao (masao.fu...@gmail.com) wrote:
On Tue, Feb 15, 2011 at 2:10 AM, Stephen Frost sfr...@snowman.net wrote:
* You removed trigger_file from the list in
doc/src/sgml/high-availability.sgml and I'm not sure I agree with
that. It's still perfectly valid and could be used by
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
On Mon, Feb 14, 2011 at 23:30, Stephen Frost sfr...@snowman.net wrote:
* In assign_csvlog_fields(), we need to cleanup memory and memory context
before return on error.
Fixed this and a couple of similar issues.
Not yet fixed.
* Stephen Frost (sfr...@snowman.net) wrote:
Ugh, sorry about that, I should have realized that needed to be done.
Updated patch attached.
Errr, for real this time.
Thanks,
Stephen
commit 25e94dcb390f56502bc46e683b438c20d2dc74e0
Author: Stephen Frost sfr...@snowman.net
On Tue, Feb 15, 2011 at 8:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 11.02.2011 22:44, Gurjeet Singh wrote:
Looks like the function get_actual_variable_range() was written with the
knowledge that virtual/hypothetical indexes may exist, but the assumption
seems
Tom Lane wrote:
I wrote:
I tried to do a pg_upgrade from 9.0.x to HEAD today. The pg_upgrade run
went through without complaint, and I could start the postmaster, but
every connection attempt fails with
psql: FATAL: could not read block 0 in file base/11964/11683: read only
0 of
On Feb 12, 2011, at 9:53 AM, Alex Hunsaker wrote:
On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin al...@commandprompt.com wrote:
Anyway in playing with this patch a bit more I found another bug
return [[]]; would segfault.
So find attached a v9 that:
- fixes above segfault
- made
Hello guys,
I am a lecturer at Kharkiv National University of Radio Electronics and I have
a proposal for you.
My students have to make their science projects during this half-year. I would
like to involve some of them in PostgreSQL to give them an opportunity to work
on a real project
Tom Lane wrote:
I wrote:
I tried to do a pg_upgrade from 9.0.x to HEAD today. The pg_upgrade run
went through without complaint, and I could start the postmaster, but
every connection attempt fails with
psql: FATAL: could not read block 0 in file base/11964/11683: read only
0 of
* Stephen Frost (sfr...@snowman.net) wrote:
I'd be happy to go back to the original patch/idea of just the simple
addition of %U as an option for log_line_prefix.
Updated patch attached which just adds %U support to log_line_prefix.
Will work on adding CSV support for this in 9.2, along with
On Tue, Feb 15, 2011 at 10:26 AM, Stephen Frost sfr...@snowman.net wrote:
* Stephen Frost (sfr...@snowman.net) wrote:
I'd be happy to go back to the original patch/idea of just the simple
addition of %U as an option for log_line_prefix.
Updated patch attached which just adds %U support to
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the whole, I don't think that sepgsql-regtest.pp should be built or
installed at all during the build phase. It ought to be generated
during regression test startup, instead.
You have to manually install and enable it
On Sat, Feb 12, 2011 at 6:16 AM, Lukas Eder lukas.e...@gmail.com wrote:
I had tried that before. That doesn't seem to change anything. JDBC still
expects 6 OUT parameters, instead of just 1...
Oh, hrm. I thought you were trying to fix the return value, rather
than the signature.
I am not sure
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
The payoff
(getting %U) seems quite out of proportion to the potential downsides
of making a change of this type at this late date.
I'd be happy to go back to the original patch/idea of just the simple
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 14.02.2011 21:49, Alvaro Herrera wrote:
Thanks to Noah Misch's review of the keylock patch I noticed that
pageinspect's heap_page_items(bytea) function returns infomask and
infomask2 as smallint (signed). But the fields in the
On Tue, Feb 15, 2011 at 10:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
The payoff
(getting %U) seems quite out of proportion to the potential downsides
of making a change of this type at this late date.
I'd
On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 14.02.2011 21:49, Alvaro Herrera wrote:
Thanks to Noah Misch's review of the keylock patch I noticed that
pageinspect's heap_page_items(bytea) function returns
On 02/15/2011 10:34 AM, Robert Haas wrote:
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lanet...@sss.pgh.pa.us wrote:
On the whole, I don't think that sepgsql-regtest.pp should be built or
installed at all during the build phase. It ought to be generated
during regression test startup, instead.
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't see any reason that the old version of the function couldn't be
dropped in the upgrade script. It's not likely anything would be
depending on it, is it?
I don't see much
On Tue, Feb 15, 2011 at 10:50 AM, Andrew Dunstan and...@dunslane.net wrote:
On 02/15/2011 10:34 AM, Robert Haas wrote:
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lanet...@sss.pgh.pa.us wrote:
On the whole, I don't think that sepgsql-regtest.pp should be built or
installed at all during the build
On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't see any reason that the old version of the function couldn't be
dropped in the upgrade script. It's not
Robert Haas robertmh...@gmail.com writes:
Something along these lines would be OK with me (I haven't yet
validated every detail), but there were previous objections to adding
any new fields to log_line_prefix until we had a flexible CSV format.
I think that's raising the bar a bit too high,
Robert Haas robertmh...@gmail.com writes:
Those are good points. My point was just that you can't actually
build that file at the time you RUN the regression tests, because you
have to build it first, then install it, then run the regression
tests. It could be a separate target, like 'make
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What risk? And at least we'd be trying to do it cleanly, in a manner
that should work for at least 99% of users. AFAICT, Heikki's proposal
is break it for everyone, and damn the
On Tue, Feb 15, 2011 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Something along these lines would be OK with me (I haven't yet
validated every detail), but there were previous objections to adding
any new fields to log_line_prefix until we had a
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Given that this has been like this right along, I don't see why it's
all that urgent to force a half-baked solution into 9.1. I'm also
concerned that if we do do that, you'll lose motivation to work on
cleaning it up for 9.2 ;-)
The addition to
On Tue, Feb 15, 2011 at 11:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What risk? And at least we'd be trying to do it cleanly, in a manner
that should work for at least 99% of users.
On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Those are good points. My point was just that you can't actually
build that file at the time you RUN the regression tests, because you
have to build it first, then install it, then
* Robert Haas (robertmh...@gmail.com) wrote:
Well, I guess the other option is to just add it to the format, full
stop. But as someone pointed out previously, that's not a terribly
scalable solution, but perhaps it could be judged adequate for this
particular case.
Think I suggested that at
On 15.02.2011 18:03, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 10:53 AM, Tom Lanet...@sss.pgh.pa.us wrote:
What risk? And at least we'd be trying to do it cleanly, in a manner
that should work for at least 99% of users. AFAICT, Heikki's proposal
is
On Tue, Feb 15, 2011 at 11:13 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Well, I guess the other option is to just add it to the format, full
stop. But as someone pointed out previously, that's not a terribly
scalable solution, but perhaps it
On Tue, 2011-02-15 at 01:45 -0500, Jaime Casanova wrote:
On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
Here's the latest patch for sync rep.
I was looking at this code and found something in SyncRepWaitOnQueue
we declare a timeout variable that is a long and
Hi,
I realize that you didn't keep the \dx behavior I had, that when given
an extension name it would list all the objects contained in the
extension. Now that's a pretty simple query:
select pg_describe_object(classid, objid, 0)
from pg_depend d
join pg_extension e on d.refclassid =
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Those are good points. My point was just that you can't actually
build that file at the time you RUN the regression tests, because you
have
On Sat, 2011-02-12 at 14:11 -0800, Daniel Farina wrote:
This is another bit of the syncrep patch split out.
I will revisit the replication timeout one Real Soon, I promise -- but
I have a couple things to do today that may delay that until the
evening.
On 15.02.2011 18:42, Simon Riggs wrote:
On Sat, 2011-02-12 at 14:11 -0800, Daniel Farina wrote:
This is another bit of the syncrep patch split out.
I will revisit the replication timeout one Real Soon, I promise -- but
I have a couple things to do today that may delay that until the
evening.
On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Those are good points. My point was just that you can't actually
build
On Tue, Feb 15, 2011 at 11:49 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 15.02.2011 18:42, Simon Riggs wrote:
On Sat, 2011-02-12 at 14:11 -0800, Daniel Farina wrote:
This is another bit of the syncrep patch split out.
I will revisit the replication timeout one Real
On 15.02.2011 18:52, Robert Haas wrote:
On Tue, Feb 15, 2011 at 11:49 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It would be wise to also transmit the epoch in addition to xmin, to avoid
confusion if the standby is 2 billion transactions behind.
That case is probably
On 02/15/2011 11:13 AM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Well, I guess the other option is to just add it to the format, full
stop. But as someone pointed out previously, that's not a terribly
scalable solution, but perhaps it could be judged adequate for
Gurjeet Singh singh.gurj...@gmail.com writes:
Also attached is the patch expose_IndexSupportInitialize.patch, that makes
the static function IndexSupportInitialize() global so that the Index
Advisor doesn't have to reinvent the wheel to prepare an index structure
with opfamilies and opclasses.
On Mon, Feb 14, 2011 at 12:08 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I committed the patch with those changes, and some minor comment tweaks and
other kibitzing.
+ * 'd' means a
On Tue, Feb 15, 2011 at 1:11 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Feb 14, 2011 at 2:08 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I committed the patch with those changes, and some
On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
sends a status update every time the WAL is
On 02/15/2011 06:55 AM, Robert Haas wrote:
On Tue, Feb 15, 2011 at 3:31 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Feb 15, 2011 at 01:27, Robert Haasrobertmh...@gmail.com wrote:
However, file_fdw is in pretty serious trouble because (1) the copy
API patch that it
On Tue, Feb 15, 2011 at 11:42 AM, Simon Riggs si...@2ndquadrant.com wrote:
Patch attached, no docs yet, but the patch is clear.
I'm looking to commit this in next 24 hours barring objections and/or
test failures.
Looks pretty good to me, though I haven't tested it. I like some of
the safety
On Tue, Feb 15, 2011 at 11:37 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Do we want to get that back in, and in which psql command? It could
well be that having \dx list extension and \dx name list extension's
objects wasn't the best design around, and it could be that it's not
useful
On Tue, Feb 15, 2011 at 12:15 PM, Robert Haas robertmh...@gmail.com wrote:
On another disk, I think that those warning messages are a bad idea.
That could fill up someone's disk really quickly.
On another disk? What the heck am I talking about?
On another point? On another note? Anyway, you
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
I realize that you didn't keep the \dx behavior I had, that when given
an extension name it would list all the objects contained in the
extension.
Sure I did: \dx+
regards, tom lane
--
Sent via pgsql-hackers mailing
robertmh...@gmail.com (Robert Haas) writes:
It does, but frankly I don't see much reason to change it, since it's
been working pretty well on the whole. Andrew was on point when he
mentioned that it's not obvious what committers get out of working on
other people's patches. Obviously, the
On Mon, Feb 14, 2011 at 5:13 PM, Daniel Farina dan...@heroku.com wrote:
On Mon, Feb 14, 2011 at 12:48 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Feb 12, 2011 at 8:58 AM, Daniel Farina dan...@heroku.com wrote:
Context diff equivalent attached.
Thanks for the patch!
As I said
Tom Lane t...@sss.pgh.pa.us writes:
Sure I did: \dx+
And I believe I did test that. Sorry for the noise, really. (shame)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
After I re-added the closing /para in plperl.sgml:235 these errors
disappeared, and the
resulting html looks fine too. v10 with just this single change is attached.
So is this ready for committer?
Best,
David
--
Sent via pgsql-hackers
On Feb 15, 2011, at 7:45 PM, David E. Wheeler wrote:
On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
After I re-added the closing /para in plperl.sgml:235 these errors
disappeared, and the
resulting html looks fine too. v10 with just this single change is attached.
So is this ready
On Sun, Feb 13, 2011 at 7:52 AM, Peter Eisentraut pete...@gmx.net wrote:
psql -l doesn't process psqlrc. Historically, this was probably not
useful, hence no one cared. But with the linestyle option it's useful.
So I propose the attached tweak.
As a violent hater of the new linestyle, +1
Gurjeet Singh singh.gurj...@gmail.com writes:
On Tue, Feb 15, 2011 at 8:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 11.02.2011 22:44, Gurjeet Singh wrote:
One one hand get_actual_variable_range() expects that virtual indexes do
not
have an OID assigned, on the
On 02/15/2011 12:37 PM, Greg Stark wrote:
On Tue, Feb 15, 2011 at 6:12 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
from what I can see upstream libedit actually has utf8 support for a while
now (as well as some other fixes) but the debian libedit version (and also
the one of other
On Feb 15, 2011, at 9:49 AM, Alexey Klyukin wrote:
After I re-added the closing /para in plperl.sgml:235 these errors
disappeared, and the
resulting html looks fine too. v10 with just this single change is attached.
So is this ready for committer?
Yes.
Awesom, thanks Alexey Alex!
On Tue, 2011-02-15 at 12:20 -0500, Robert Haas wrote:
On Tue, Feb 15, 2011 at 12:15 PM, Robert Haas robertmh...@gmail.com wrote:
On another disk, I think that those warning messages are a bad idea.
That could fill up someone's disk really quickly.
On another disk? What the heck am I
* Andrew Dunstan (and...@dunslane.net) wrote:
On 02/15/2011 11:13 AM, Stephen Frost wrote:
Think I suggested that at one point. I'm all for doing that on a major
version change like this one, but I think we already had some concerns
about that on this thread (Andrew maybe?).
I could live
I wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
I think you'd be interested into this reworked SQL query. It should be
providing exactly the script file you need as an upgrade from unpackaged.
This seems overly complicated. I have a version of it that I'll publish
as soon as I've
On Tue, Feb 15, 2011 at 1:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm actually surprised we don't need to distinguish them in more places, but
nevertheless it feels like we should have that info available more
conveniently, and without requiring a catalog lookup
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
As the patch stands, we have to do get_rel_relkind() in a couple of
places in parse analysis and the planner to distinguish a foreign table
from a regular one. As the patch stands, there's nothing in
RangeTblEntry (which is what
On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
Because the invocation that actually recurses sets up the scene for
failure.
That's what we're observing, but I can't figure out why it is. If you
can, could you explain it?
It actually makes sense to me that the arguments should be
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: 15 February 2011 16:52
To: Tom Lane
Cc: Andrew Dunstan; Kohei Kaigai; Stephen Frost; KaiGai Kohei; PgHacker
Subject: Re: [HACKERS] sepgsql contrib module
On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane
On mån, 2011-02-14 at 15:08 -0500, Tom Lane wrote:
Umm ... we are not requiring version names to be numbers.
That's certainly interesting. Why?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote:
I guess the real question is what's Peter's concrete objection to the
double-dash method?
It just looks a bit silly and error prone. And other packaging systems
have been doing without it for decades.
--
Sent via pgsql-hackers mailing list
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-02-14 at 15:08 -0500, Tom Lane wrote:
Umm ... we are not requiring version names to be numbers.
That's certainly interesting. Why?
There isn't any packaging system anywhere on the planet that requires
them to be purely numeric. By the
On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote:
I guess the real question is what's Peter's concrete objection to the
double-dash method?
It just looks a bit silly and error prone. And other packaging systems
have
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote:
I guess the real question is what's Peter's concrete objection to the
double-dash method?
It just looks a bit silly and error prone. And other packaging systems
have been doing without it for
On Feb 15, 2011, at 12:32 PM, Tom Lane wrote:
Aside from the double-dash method, we kicked around using colons and
pluses as separators (and then forbidding just those characters in
extension and version names). Any of those would be workable, but it's
not clear to me that any of them have
On 15.02.2011 21:13, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
As the patch stands, we have to do get_rel_relkind() in a couple of
places in parse analysis and the planner to distinguish a foreign table
from a regular one. As the patch stands, there's
On 15.02.2011 21:00, Robert Haas wrote:
On Tue, Feb 15, 2011 at 1:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm actually surprised we don't need to distinguish them in more places, but
nevertheless it feels like we should have that info available more
conveniently,
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 15.02.2011 21:13, Tom Lane wrote:
Hmm. I don't have a problem with adding relkind to the planner's
RelOptInfo, but it seems to me that if parse analysis needs to know
this, you have put functionality into parse analysis that
On Tue, Feb 15, 2011 at 3:26 PM, marcin mank marcin.m...@gmail.com wrote:
On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote:
I guess the real question is what's Peter's concrete objection to the
double-dash method?
It
On Mon, Feb 14, 2011 at 6:49 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Marti Raudsepp's message of lun feb 14 19:39:25 -0300 2011:
On Fri, Feb 11, 2011 at 09:13, Noah Misch n...@leadboat.com wrote:
The patch had a trivial conflict in planner.c, plus plenty of offsets.
On Tue, 2011-02-15 at 12:15 -0500, Robert Haas wrote:
Looks pretty good to me, though I haven't tested it. I like some of
the safety valves you put in there, but I don't understand this part
Reworked logic covering all feedback, plus tests, plus docs.
Last comments before commit please.
--
On Feb 15, 2011, at 1:15 PM, Robert Haas wrote:
Yeah, that bug is fixed with the attached, though I am rethinking this
bit.
I am thinking that the statute of limitations has expired on this
patch, and that we should mark it Returned with Feedback and continue
working on it for 9.2. I know
Excerpts from Robert Haas's message of mar feb 15 18:15:38 -0300 2011:
I am thinking that the statute of limitations has expired on this
patch, and that we should mark it Returned with Feedback and continue
working on it for 9.2. I know it's a valuable feature, but I think
we're out of time.
Hi all,
I assumed array_cat would behave similarly to array || array, but it
appears not when it comes to NULLs. Shouldn't these have identical
functionality? The attached patch makes it so, although it would
break existing code.
Would such a change have any knock-on effect, or cause
2011/2/15 Thom Brown t...@linux.com:
Hi all,
I assumed array_cat would behave similarly to array || array, but it
appears not when it comes to NULLs. Shouldn't these have identical
functionality? The attached patch makes it so, although it would
break existing code.
There is bugreport and
Thom Brown t...@linux.com writes:
I assumed array_cat would behave similarly to array || array, but it
appears not when it comes to NULLs. Shouldn't these have identical
functionality? The attached patch makes it so, although it would
break existing code.
That patch is the hard way: the
Tom Lane t...@sss.pgh.pa.us writes:
Just for the archives' sake: the '@extschema@' business did turn out to
be important, at least for tsearch2 where it's necessary to distinguish
the objects it's dealing with from similarly-named objects in
pg_catalog. So this is what I used to generate the
On 15 February 2011 21:46, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/2/15 Thom Brown t...@linux.com:
Hi all,
I assumed array_cat would behave similarly to array || array, but it
appears not when it comes to NULLs. Shouldn't these have identical
functionality? The
On 02/15/2011 04:49 PM, Dimitri Fontaine wrote:
Ah well sed makes it simpler to read, but it won't be usable in windows.
You can make perl do the same stuff (and perl has psed anyway), and perl
is required for MSVC builds.
cheers
andrew
--
Sent via pgsql-hackers mailing list
On 15 February 2011 21:47, Tom Lane t...@sss.pgh.pa.us wrote:
Also, so far as I can see array_cat *is* ||, so I'm not sure what
discrepancy in behavior you're on about.
You've confused me now. I had a case where I replaced || with , and
surrounded it with array_cat, and the result differed,
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Do we want to add such a query in the docs to help pgfoundry authors to
write their own 'from unpackaged' scripts?
[ scratches head ... ] Why is your version generating so many
unnecessary @extschema@ uses?
regards, tom
On Tue, Feb 15, 2011 at 4:15 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2011-02-15 at 12:15 -0500, Robert Haas wrote:
Looks pretty good to me, though I haven't tested it. I like some of
the safety valves you put in there, but I don't understand this part
Reworked logic covering all
1 - 100 of 135 matches
Mail list logo
