Andres Freund írta:
> On Fri, Aug 13, 2010 at 09:36:00PM +0200, Boszormenyi Zoltan wrote:
>
>> Tom Lane írta:
>>
>>> Boszormenyi Zoltan writes:
>>>
>>>
attached is a WIP patch that will eventually implement
partial replication, with the following syntax:
>>>
2010/8/14 Itagaki Takahiro :
> 2010/8/10 Tom Lane :
>> Eventually it might be nice to have some sort of way to specify the
>> estimate to use for any aggregate function --- but for a near-term
>> fix maybe we should just hard-wire a special case for array_agg in
>> count_agg_clauses_walker().
>
> T
Bruce Momjian writes:
> Tom Lane wrote:
>> I'm not sure whether there is any clear rule for what rows you get when
>> grouping by a non-PK column in mysql, but it'll let you do it.
> I understand this. The issue is how many people who complained about
> our GROUP BY behavior were grouping by som
Tom Lane wrote:
> Stephen Frost writes:
> > * Bruce Momjian (br...@momjian.us) wrote:
> >> My guess is our new 9.1 functionality will reduce requests for this
> >> features, so we can just not list it anymore. If they still ask, we can
> >> re-added this not-wanted item.
>
> > I'm not so sure...
Stephen Frost writes:
> * Bruce Momjian (br...@momjian.us) wrote:
>> My guess is our new 9.1 functionality will reduce requests for this
>> features, so we can just not list it anymore. If they still ask, we can
>> re-added this not-wanted item.
> I'm not so sure... I expect we're going to get
Bruce Momjian writes:
> Well, as worded, it says we have to group by everything, which is not
> true in 9.1, so I figured let's see what feedback we get and we can add
> a new one if we want, but our old argument is invalid, since we did
> implement part of what we said we wouldn't. ;-)
Uh, no.
Stephen Frost wrote:
-- Start of PGP signed section.
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > My guess is our new 9.1 functionality will reduce requests for this
> > features, so we can just not list it anymore. If they still ask, we can
> > re-added this not-wanted item.
>
> I
2010/8/10 Tom Lane :
> Eventually it might be nice to have some sort of way to specify the
> estimate to use for any aggregate function --- but for a near-term
> fix maybe we should just hard-wire a special case for array_agg in
> count_agg_clauses_walker().
The attached patch is the near-term fix
On Aug 13, 2010, at 5:20 PM, Tom Lane wrote:
> According to a discussion over in Fedora-land, $subject is true:
> http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html
>
> I see several calls in plpython.c that seem to refer to PyCObject stuff.
> Anybody have any idea if we need t
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> My guess is our new 9.1 functionality will reduce requests for this
> features, so we can just not list it anymore. If they still ask, we can
> re-added this not-wanted item.
I'm not so sure... I expect we're going to get people complaining tha
Tom Lane wrote:
> Log Message:
> ---
> Recognize functional dependency on primary keys. This allows a table's
> other columns to be referenced without listing them in GROUP BY, so long as
> the primary key column(s) are listed in GROUP BY.
>
> Eventually we should also allow functional de
On Fri, Aug 13, 2010 at 7:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> I have taken a crack at fixing this but someone who understands DTrace
>> better than I do may want to check and see if the changes look sane.
>> It appears to me that we have no documentation - not even so much as a
>> sou
2010/8/11 Hans-Jürgen Schönig :
> now, the problem is: i cannot easily create additional indexes as i have too
> many possible "second" conditions here.
>
Is it just me or is this description of the problem not very specific?
Can you give more examples of your queries and explain what kind of
pla
According to a discussion over in Fedora-land, $subject is true:
http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html
I see several calls in plpython.c that seem to refer to PyCObject stuff.
Anybody have any idea if we need to do something about this?
reg
Robert Haas writes:
> I have taken a crack at fixing this but someone who understands DTrace
> better than I do may want to check and see if the changes look sane.
> It appears to me that we have no documentation - not even so much as a
> source code comment - explaining how these probes are suppo
On Fri, Aug 13, 2010 at 6:38 PM, Robert Haas wrote:
> On Fri, Aug 13, 2010 at 5:51 PM, Tom Lane wrote:
>> rh...@postgresql.org (Robert Haas) writes:
>>> Include the backend ID in the relpath of temporary relations.
>>
>> A couple of the buildfarm members don't like this patch. I think you
>> mis
Alvaro Herrera writes:
> CREATE TABLE foo AS SELECT a, a % 10 AS b FROM generate_series(1, 10) a;
> CREATE INDEX a_b ON foo (b);
> CREATE VIEW bar AS SELECT a, b, lead(a, 1) OVER () FROM foo;
> explain select a, b, lead(a, 1) over () from foo where b = 2;
> explain select * from bar where b =
Josh Berkus writes:
>> Another rather basic problem is that you've
>> got to pass system catalog updates downstream (in case they affect
>> the tables being replicated) but if you want partial replication then
>> many of those updates will be incorrect for the slave machine.
> Couldn't this be ta
Hi,
I've got a table and view defined like this:
CREATE TABLE foo AS SELECT a, a % 10 AS b FROM generate_series(1, 10) a;
CREATE INDEX a_b ON foo (b);
CREATE VIEW bar AS SELECT a, b, lead(a, 1) OVER () FROM foo;
Now, if I query the table directly instead of going through the view, a
WHERE co
On 08/13/2010 03:46 PM, Joseph Adams wrote:
On Fri, Aug 13, 2010 at 2:02 PM, David Fetter wrote:
On Fri, Aug 13, 2010 at 01:33:06PM -0400, Robert Haas wrote:
Maybe so, but it's not clear the interface that Joseph implemented is
the one everyone wants...
Fair enough. What's the interface no
> Another rather basic problem is that you've
> got to pass system catalog updates downstream (in case they affect
> the tables being replicated) but if you want partial replication then
> many of those updates will be incorrect for the slave machine.
Couldn't this be taken care of by replicatin
Pavel Stehule writes:
> attached updated \sf implementation. It is little bit simplyfied with
> support a pager and output forwarding.
The line number argument to this greatly complicates the code but
doesn't appear to me to have much practical use. Why would you bother
with that?
On Fri, Aug 13, 2010 at 12:11 PM, Alvaro Herrera
wrote:
> src/include/port.h?
Oh, hey, look at that. Any thought on what to about the fact that our
two existing copies of utf2ucs() don't match? (one tests against 0xf8
where the other against 0xf0)
--
Robert Haas
EnterpriseDB: http://www.enter
On Fri, Aug 13, 2010 at 2:02 PM, David Fetter wrote:
> On Fri, Aug 13, 2010 at 01:33:06PM -0400, Robert Haas wrote:
>> Maybe so, but it's not clear the interface that Joseph implemented is
>> the one everyone wants...
>
> Fair enough. What's the interface now in a nutshell? Lack of
> nutshells m
On Fri, Aug 13, 2010 at 09:36:00PM +0200, Boszormenyi Zoltan wrote:
> Tom Lane írta:
> > Boszormenyi Zoltan writes:
> >
> >> attached is a WIP patch that will eventually implement
> >> partial replication, with the following syntax:
> > This fundamentally cannot work, as it relies on system catalo
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> attached is a WIP patch that will eventually implement
>> partial replication, with the following syntax:
>>
>
> This fundamentally cannot work, as it relies on system catalogs to be
> valid during recovery.
Just like Hot Standby, no? What
Boszormenyi Zoltan writes:
> attached is a WIP patch that will eventually implement
> partial replication, with the following syntax:
This fundamentally cannot work, as it relies on system catalogs to be
valid during recovery. Another rather basic problem is that you've
got to pass system catalo
Mike Fowler writes:
> On 11/08/10 21:27, Tom Lane wrote:
>> Yes. Mike, are you expecting to submit a new version before the end of
>> the week?
> Yes and here it is, apologies for the delay. I have re-implemented
> xml_is_well_formed such that it is sensitive to the XMLOPTION. The
> additional
Robert Haas writes:
> On Fri, Aug 13, 2010 at 1:50 PM, Tom Lane wrote:
>> AFAICS the version in mbprint.c is flat out wrong, and the only reason
>> nobody's noticed is that it should never get passed a more-than-4-byte
>> sequence anyway.
> Should we fix it, then, and if so how far should we go
On Fri, Aug 13, 2010 at 1:50 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Robert Haas's message of vie ago 13 12:50:13 -0400 2010:
>>> Oh, hey, look at that. Any thought on what to about the fact that our
>>> two existing copies of utf2ucs() don't match? (one tests against 0xf8
On Fri, Aug 13, 2010 at 01:33:06PM -0400, Robert Haas wrote:
> On Fri, Aug 13, 2010 at 1:05 PM, David Fetter wrote:
> > On Fri, Aug 13, 2010 at 12:59:48PM -0400, Robert Haas wrote:
> >> On Fri, Aug 13, 2010 at 12:55 PM, Joseph Adams
> >> wrote:
> >> > Indeed, a built-in JSON data type will certai
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of vie ago 13 12:50:13 -0400 2010:
>> Oh, hey, look at that. Any thought on what to about the fact that our
>> two existing copies of utf2ucs() don't match? (one tests against 0xf8
>> where the other against 0xf0)
> I'm not sure why i
Excerpts from Robert Haas's message of vie ago 13 12:50:13 -0400 2010:
> On Fri, Aug 13, 2010 at 12:11 PM, Alvaro Herrera
> wrote:
> > src/include/port.h?
>
> Oh, hey, look at that. Any thought on what to about the fact that our
> two existing copies of utf2ucs() don't match? (one tests against
On Fri, Aug 13, 2010 at 1:10 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> > 3. 64-bit arithmetic. Right now, mul_var() and div_var() use int for
>> > arithmetic, but haven't we given up on supporting platforms without
>> > long long? I'm not sure I'm motivated enough to write the patch
>> > mys
On Fri, Aug 13, 2010 at 1:05 PM, David Fetter wrote:
> On Fri, Aug 13, 2010 at 12:59:48PM -0400, Robert Haas wrote:
>> On Fri, Aug 13, 2010 at 12:55 PM, Joseph Adams
>> wrote:
>> > Indeed, a built-in JSON data type will certainly not need it.
>> > However, users may want to return enums from proc
Tom Lane wrote:
> > 3. 64-bit arithmetic. Right now, mul_var() and div_var() use int for
> > arithmetic, but haven't we given up on supporting platforms without
> > long long? I'm not sure I'm motivated enough to write the patch
> > myself, but it seems like 64-bit arithmetic would give us a lot
On Fri, Aug 13, 2010 at 12:59:48PM -0400, Robert Haas wrote:
> On Fri, Aug 13, 2010 at 12:55 PM, Joseph Adams
> wrote:
> > Indeed, a built-in JSON data type will certainly not need it.
> > However, users may want to return enums from procedures written in
> > C, and this function provides a way to
Joseph Adams writes:
> On Fri, Aug 13, 2010 at 10:46 AM, Robert Haas wrote:
>> + if (sub_end + len > e)
>> + {
>> + Assert(false); /* Clipped multibyte
>> character */
>> + break;
>> + }
> If I simply
On Fri, Aug 13, 2010 at 12:55 PM, Joseph Adams
wrote:
> Indeed, a built-in JSON data type will certainly not need it.
> However, users may want to return enums from procedures written in C,
> and this function provides a way to do it.
Yeah, but I can't see accepting it on speculation. We'll add
Robert Haas writes:
> On Fri, Aug 13, 2010 at 12:49 PM, Tom Lane wrote:
>> Also, it'd be better if BBB and FFF were marked up as
>> rather than , see examples elsewhere in that file.
> I see. How should I mark tBBB_FFF?
I'd do
tBBB_FFF
regards, tom lane
--
Sent via
On Fri, Aug 13, 2010 at 10:46 AM, Robert Haas wrote:
> On Fri, Aug 13, 2010 at 5:45 AM, Joseph Adams
> wrote:
>> getEnumLabelOids
>> * Useful-ometer: ()---o
>> * Rationale: There is currently no streamlined way to return a custom
>> enum value from a PostgreSQL f
On Fri, Aug 13, 2010 at 12:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> Here is an updated patch. It's in context-diff format this time,
>
> Thanks, I appreciate that ;-)
>
> This looks committable to me, with a couple of tiny suggestions:
Woo hoo!
> In the text added to storage.sgml, s/tem
Robert Haas writes:
> Here is an updated patch. It's in context-diff format this time,
Thanks, I appreciate that ;-)
This looks committable to me, with a couple of tiny suggestions:
In the text added to storage.sgml, s/temporary relation/temporary relations/.
Also, it'd be better if BBB and FF
Excerpts from Robert Haas's message of vie ago 13 12:00:32 -0400 2010:
> On Fri, Aug 13, 2010 at 3:12 AM, Joseph Adams
> wrote:
> > I've attached another patch that moves utf8_to_unicode to src/port per
> > Robert Haas's suggestion.
> >
> > This patch itself is not quite as elegant as the first on
On Thu, Aug 12, 2010 at 9:43 PM, Fujii Masao wrote:
> On Fri, Aug 13, 2010 at 10:24 AM, Robert Haas wrote:
>> On Thu, Aug 12, 2010 at 12:11 AM, Fujii Masao wrote:
>>> It appears to me that RecordTransactionCommit() only needs to WAL-log
>>> shared invalidation messages when wal_level is
On Fri, Aug 13, 2010 at 3:12 AM, Joseph Adams
wrote:
> I've attached another patch that moves utf8_to_unicode to src/port per
> Robert Haas's suggestion.
>
> This patch itself is not quite as elegant as the first one because it
> puts platform-independent code that "belongs" in wchar.c into src/po
On Thu, Aug 12, 2010 at 5:54 PM, Tom Lane wrote:
> I wrote:
>> I wonder if the problem is not so much libpqwalreceiver as the
>> walreceiver process. Maybe an ordinary backend process does some
>> prerequisite initialization that walreceiver is missing. Hard to
>> guess what, though ... I can't
On Thu, Aug 12, 2010 at 9:37 PM, Fujii Masao wrote:
> Before 9.0, since xact_redo_commit always calls TransactionIdCommitTree,
> TransactionIdSetStatusBit always receives InvalidXLogRecPtr. In 9.0,
> xact_redo_commit calls TransactionIdCommitTree only when hot standby is
> disabled. OTOH, when hot
On Fri, Aug 13, 2010 at 5:45 AM, Joseph Adams
wrote:
> getEnumLabelOids
> * Useful-ometer: ()---o
> * Rationale: There is currently no streamlined way to return a custom
> enum value from a PostgreSQL function written in C. This function
> performs a batch lookup
2010/8/12 PostgreSQL - Hans-Jürgen Schönig :
> as tom pointed out - this is not possible.
> there is no limit 20 in my case - i just used it to indicate that limiting
> does not make the index scan possible which it does in some other cases.
I came up with this:
explain analyze select * from (se
On Wed, Aug 4, 2010 at 5:34 PM, Dimitri Fontaine wrote:
>> On Tue, 2010-08-03 at 11:10 -0400, Robert Haas wrote:
>>> Or vi.
>>
>> cough.
>
> Well, I guess letting newcomers know about tools of choice amongst
> regular contributors is a good idea, but the best editor you can find
> around is the on
Fujii Masao writes:
> pg_dump allows us to select multiple target tables by using
> multiple -t switches, but pg_restore does not. So, when
> restoring multiple tables, we have to run pg_restore more
> than once as follows. This is a pain to me.
Use the list facilities, options -l and -L.
> Is i
Viktor Valy writes:
> Thanks for the advice!Yes, we are new to linux too :)We have chosen
> Eclipse, because we have already experience with it.However, after
> downloading the code from CVS, we can't build it, because of some
> include commands in tutorial / complex.c says "No such file or
> dire
On 13/08/10 10:45, Joseph Adams wrote:
This patch doesn't include tests . How would I go about writing them?
I have made the JSON data type built-in, and I will post that patch
shortly (it depends on this one). The built-in JSON data type uses
all of these utility functions, and the tests for
I factored out the general-purpose utility functions in the JSON data
type code into a patch against HEAD. I have made a few changes to
them since I posted about them earlier (
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00692.php ).
A summary of the utility functions along with some
On Fri, Aug 13, 2010 at 2:33 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 13/08/10 09:27, Boxuan Zhai wrote:
>
>> I have renewed the merge.sql and merge.out in regress. Please have a look.
>>
>
> Thanks.
>
> Did you change the way DO INSTEAD rules are handled already?
On Tue, Jul 27, 2010 at 1:31 PM, Robert Haas wrote:
> On Sat, Jul 24, 2010 at 10:34 PM, Joseph Adams
> wrote:
>> In src/include/mb/pg_wchar.h , there is a function unicode_to_utf8 ,
>> but no corresponding utf8_to_unicode . However, there is a static
>> function called utf2ucs that does what utf
57 matches
Mail list logo
