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 o
On Tue, Feb 15, 2011 at 01:27, Robert Haas 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. file_encoding problem; the
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 se
- 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
> > n
On Tue, Feb 15, 2011 at 6:12 AM, Stefan Kaltenbrunner
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 maybe most of the
> is
On Tue, Feb 15, 2011 at 3:31 AM, Itagaki Takahiro
wrote:
> On Tue, Feb 15, 2011 at 01:27, Robert Haas 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 somet
On Tue, Feb 15, 2011 at 4:31 AM, Itagaki Takahiro
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 array_union_all as an alia
On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao 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 processes than
> walrece
On Tue, Feb 15, 2011 at 12:46 AM, Itagaki Takahiro
wrote:
> On Mon, Feb 14, 2011 at 23:30, Stephen Frost 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. Switched mem
On Fri, Feb 11, 2011 at 6:20 PM, Kevin Grittner
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 pgsql-hackers mailing
* 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 log_line_pref
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 ass
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 thi
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Tue, Feb 15, 2011 at 2:10 AM, Stephen Frost 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 someone
> > i
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> On Mon, Feb 14, 2011 at 23:30, Stephen Frost 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. Switched mem
* 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
Date: Tue Feb
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
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 onl
On Feb 12, 2011, at 9:53 AM, Alex Hunsaker wrote:
> On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin 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 plperl_sv_to_literal
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 instea
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 onl
* 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 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 log_line_prefix
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane 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 before you can run t
On Sat, Feb 12, 2011 at 6:16 AM, Lukas Eder 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 how to fix the sig
Stephen Frost 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
> addition of %
Heikki Linnakangas 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 tuple header are
>> 16 bits u
On Tue, Feb 15, 2011 at 10:37 AM, Tom Lane wrote:
> Stephen Frost 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
On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane wrote:
> Heikki Linnakangas 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 (sign
On 02/15/2011 10:34 AM, Robert Haas wrote:
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane 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
Robert Haas writes:
> On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane 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 point in taking the risk.
What ri
On Tue, Feb 15, 2011 at 10:50 AM, Andrew Dunstan wrote:
> On 02/15/2011 10:34 AM, Robert Haas wrote:
>> On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane 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 generate
On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane 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 i
Robert Haas 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, personally, but I do
Robert Haas 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 policy', but I don'
Robert Haas writes:
> On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane 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 torpedoes".
> I must be confused.
On Tue, Feb 15, 2011 at 10:57 AM, Tom Lane wrote:
> Robert Haas 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 th
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 wrote:
> Robert Haas writes:
>> On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane 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 e
On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane wrote:
> Robert Haas 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 c
* 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
On 15.02.2011 18:03, Tom Lane wrote:
Robert Haas writes:
On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane 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 torpe
On Tue, Feb 15, 2011 at 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
On Tue, 2011-02-15 at 01:45 -0500, Jaime Casanova wrote:
> On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs 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 another that
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 writes:
> On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane wrote:
>> Robert Haas 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
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.
>
> https://github.com/fdr/postgre
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.
h
On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane wrote:
>>> Robert Haas 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
On Tue, Feb 15, 2011 at 11:49 AM, Heikki Linnakangas
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 Soon, I promise --
On 15.02.2011 18:52, Robert Haas wrote:
On Tue, Feb 15, 2011 at 11:49 AM, Heikki Linnakangas
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 hopelessly broken anyway.
I don't
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 this
On Tue, 2011-02-15 at 18:49 +0200, Heikki Linnakangas 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.
Yes, good idea, thanks.
That has to be the record for the fastest patch review. ;-)
--
Simon
Gurjeet Singh 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.
We are *not* doing
On Mon, Feb 14, 2011 at 12:08 AM, Fujii Masao wrote:
> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> wrote:
>> I committed the patch with those changes, and some minor comment tweaks and
>> other kibitzing.
>
> + * 'd' means a standby reply wrapped in a COPY BOTH packet.
> +
On Tue, Feb 15, 2011 at 1:11 AM, Fujii Masao wrote:
> On Mon, Feb 14, 2011 at 2:08 PM, Fujii Masao wrote:
>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
>> wrote:
>>> I committed the patch with those changes, and some minor comment tweaks and
>>> other kibitzing.
>
> I have another comme
On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote:
> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> wrote:
>> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
>> sends a status update every time the WAL is flushed. If the walreceiver is
>> busy receiving and fl
On 02/15/2011 06:55 AM, Robert Haas wrote:
On Tue, Feb 15, 2011 at 3:31 AM, Itagaki Takahiro
wrote:
On Tue, Feb 15, 2011 at 01:27, Robert Haas 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
On Tue, Feb 15, 2011 at 11:42 AM, Simon Riggs 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 valves you put in
On Tue, Feb 15, 2011 at 11:37 AM, Dimitri Fontaine
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 enough, but I know
On Tue, Feb 15, 2011 at 12:15 PM, Robert Haas 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 get the idea... hop
Dimitri Fontaine 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 list (pgsql-hackers@pos
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 wrote:
> On Mon, Feb 14, 2011 at 12:48 AM, Fujii Masao wrote:
>> On Sat, Feb 12, 2011 at 8:58 AM, Daniel Farina wrote:
>>> Context diff equivalent attached.
>>
>> Thanks for the patch!
>>
>> As I said before, the timeout which this patch provides do
Tom Lane 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)
To make changes t
On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
> After I re-added the closing 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 mail
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 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 re
On Sun, Feb 13, 2011 at 7:52 AM, Peter Eisentraut 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 from me.
--
Ro
Gurjeet Singh 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 other hand
On 02/15/2011 12:37 PM, Greg Stark wrote:
On Tue, Feb 15, 2011 at 6:12 AM, Stefan Kaltenbrunner
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 to
On Feb 15, 2011, at 9:49 AM, Alexey Klyukin wrote:
>>> After I re-added the closing 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 &
On Tue, 2011-02-15 at 12:20 -0500, Robert Haas wrote:
> On Tue, Feb 15, 2011 at 12:15 PM, Robert Haas 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?
>
>
* 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 coul
I wrote:
> Dimitri Fontaine 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 tested it on all
On Tue, Feb 15, 2011 at 1:40 PM, Heikki Linnakangas
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 like get_rel_relkind()
> does. At fi
Heikki Linnakangas 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 we have in transformLockingClau
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 dele
> -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 w
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:
http://www.postgresql.org/mailpref/pgsq
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 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 time you get
On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut 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 been doin
Peter Eisentraut 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 decades.
I can
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 hav
On 15.02.2011 21:13, Tom Lane wrote:
Heikki Linnakangas 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 we
On 15.02.2011 21:00, Robert Haas wrote:
On Tue, Feb 15, 2011 at 1:40 PM, Heikki Linnakangas
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 looku
Heikki Linnakangas 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 does not
>> belong there.
> Po
On Tue, Feb 15, 2011 at 3:26 PM, marcin mank wrote:
> On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut 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 an
On Mon, Feb 14, 2011 at 6:49 PM, Alvaro Herrera
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 wrote:
>> > The patch had a trivial conflict in planner.c, plus plenty of offsets.
>> > I've
>> > attached the rebased
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.
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 ti
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 inconsiste
2011/2/15 Thom Brown :
> 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 todo ent
Thom Brown 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 right change w
Tom Lane 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 "unpackaged"
>
On 15 February 2011 21:46, Cédric Villemain
wrote:
> 2011/2/15 Thom Brown :
>> 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 wo
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 (pgsql-h
On 15 February 2011 21:47, Tom Lane 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, and now I can't
rec
Dimitri Fontaine 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 lane
--
Sent via pgs
1 - 100 of 136 matches
Mail list logo
