On tis, 2009-12-15 at 03:34 +, Simon Riggs wrote:
> Anybody know the latest on in-memory NOTIFY?
"Returned with Feedback"
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Dec 14, 2009 at 11:09:16AM -0800, Jeff Davis wrote:
[...]
> I think "countable" is a more accurate word than "discrete". Strings are
> discrete but not countable.
Oh, no -- strings (of finite, but arbitrary length) are not discrete --
you ca
Simon Riggs wrote:
On Mon, 2009-12-14 at 11:44 +0200, Peter Eisentraut wrote:
On mån, 2009-12-14 at 08:54 +, Simon Riggs wrote:
Wednesday because that seemed a good delay to allow review. Josh and I
had discussed the value of getting patch into Alpha3, so that was my
wish and aim.
Greg Smith wrote:
> How about this: the version you updated at
> http://archives.postgresql.org/pgsql-hackers/2009-12/msg00847.php , your
> pgbenchshell_20091210.patch, worked perfectly for me except for one
> complaint I've since dropped. How about we move toward committing that
> one, an
Jaime Casanova wrote:
So in this extreme case avg tps is just 6 transactions better
Great job trying to find the spot where the code worked better. I'm not
so sure I trust pgbench results where the TPS was so low though. Which
leads us right back to exactly how Jeff measured his original r
Takahiro Itagaki wrote:
Michael Paquier wrote:
Yeah the grammar ":variable" is used to set a parameter, the user will feel
disorientated if there is no support.
The attached patch supports this new case, based on Itagaki-san's last
version.
What is the spec of "\setshell :variable" ?
On Tue, Dec 15, 2009 at 4:11 AM, Tom Lane wrote:
> Hm. Perhaps it should be a loadable plugin and not hard-linked into the
> backend? Compare dblink.
You mean that such plugin is supplied in shared_preload_libraries,
a new process is forked and the shared-memory related to walreceiver
is create
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Dec 14, 2009 at 01:32:08PM -0500, Tom Lane wrote:
[...]
> (Also, stuff like strings simply doesn't have any sane concept of a
> unique next or previous value.
If you are willing to limit the length, then yes, you could consider
them discrete
Fred Janon wrote:
Thanks Greg, at least among the socially unacceptable insults I got
the the right list to post my question in.
Aww, is somebody having a case of the Monday's?
Frankly that was all useful advice. I was pointing out that despite
what you thought, you might actually be decreas
On Sun, Dec 13, 2009 at 11:49 PM, Takahiro Itagaki
wrote:
> The attached patch [...]
Committed.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Dec 14, 2009 at 9:08 PM, Fred Janon wrote:
> Thanks Greg, at least among the socially unacceptable insults I got the the
> right list to post my question in. I am trying to get some help from
> (supposedly) helping and knowledgeable people and I get insults in return.
I don't want to make
On Mon, 2009-12-14 at 11:06 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > I definitely wouldn't presume that anybody using Hot Standby would
> > necessarily want NOTIFY to reach the standby, especially if there was an
> > overhead to doing so. If using NOTIFY is the favoured approach, I would
>
2009/12/14 KaiGai Kohei :
> IIRC, one headache issue is that user may provide well indexable conditions,
> such as "SELECT * FROM view_x WHERE id = 1234". In this case, if we strictly
> keep the order of evaluation between inside and outside of the view, its
> performance penalty will over reasonab
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> You are fine. I was just saying that at a time I was one of the few
> loud voices on this, and if this is going to happen, it will be because
> we have a team that wants to do this, not because I am being loud. I
> see the team forming nicely.
On Mon, Dec 14, 2009 at 7:29 PM, Simon Riggs wrote:
> On Fri, 2009-12-04 at 09:00 +, Simon Riggs wrote:
>> On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
>> > Here is an update partitioning syntax patch.
>> >
>> > A bug reported by Marko is fixed.
>>
>> I will review and eventually
On Tue, 2009-12-15 at 11:17 +0900, Takahiro Itagaki wrote:
> Simon Riggs wrote:
>
> > I have enough items emerging from HS to keep me busy much longer than I
> > thought. I'll run with VF if that's OK, since I have some other related
> > changes in that area and it makes sense to understand that
Simon Riggs wrote:
> I have enough items emerging from HS to keep me busy much longer than I
> thought. I'll run with VF if that's OK, since I have some other related
> changes in that area and it makes sense to understand that code also, if
> OK with you.
Sure. Many users want to see HS.
BTW,
rompt, Inc.
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4677 (20091210) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4687 (200912
Thanks Greg, at least among the socially unacceptable insults I got the the
right list to post my question in. I am trying to get some help from
(supposedly) helping and knowledgeable people and I get insults in return.
BTW, this list is listed as the list for tech questions in the pgAdmin tips,
t
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> IIRC, one headache issue is that user may provide well indexable conditions,
> such as "SELECT * FROM view_x WHERE id = 1234". In this case, if we strictly
> keep the order of evaluation between inside and outside of the view, its
> performanc
Michael Paquier wrote:
> Yeah the grammar ":variable" is used to set a parameter, the user will feel
> disorientated if there is no support.
> The attached patch supports this new case, based on Itagaki-san's last
> version.
What is the spec of "\setshell :variable" ?
Literally interpreted, it
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>> The reason why I put on the security hook in ExecScan() is to avoid the
>> problem that row-cost user defined function can be evaluated earlier
>> than row-level security policy. (I believed it was a well-known probl
Hi,
Yeah the grammar ":variable" is used to set a parameter, the user will feel
disorientated if there is no support.
The attached patch supports this new case, based on Itagaki-san's last
version. I also added a warning to tell the user that pgbench is slowing
down when using this feature.
If no
On Fri, 2009-12-04 at 09:00 +, Simon Riggs wrote:
> On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
> > Here is an update partitioning syntax patch.
> >
> > A bug reported by Marko is fixed.
>
> I will review and eventually commit this, if appropriate, though it is
> 3rd in my queu
On Mon, 2009-12-14 at 11:44 +0200, Peter Eisentraut wrote:
> On mån, 2009-12-14 at 08:54 +, Simon Riggs wrote:
> > Wednesday because that seemed a good delay to allow review. Josh and I
> > had discussed the value of getting patch into Alpha3, so that was my
> > wish and aim.
> >
> > I'm not a
Scott Bailey writes:
> Tom Lane wrote:
>> If the only interesting use-cases are ints and enums, maybe we could
>> just hard-wire it.
> I think dates could be added to that list as well.
Good point. Network addresses too probably.
> But any implementation that doesn't do ranges of timestamptz a
On Mon, 2009-12-14 at 16:39 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > What is the best way of restricting the hash table to a maximum size?
>
> There is nothing in dynahash that will enforce a maximum size against
> calling code that's not cooperating; and I'll resist any attempt to
> add
Simon Riggs writes:
> What is the best way of restricting the hash table to a maximum size?
There is nothing in dynahash that will enforce a maximum size against
calling code that's not cooperating; and I'll resist any attempt to
add such a thing, because it would create a serialization point ac
On Mon, 2009-12-14 at 15:24 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2009-12-14 at 20:32 +0200, Heikki Linnakangas wrote:
> >>> I have ensured that they are always the same size, by definition, so no
> >>> need to check.
> >>
> >> How did you ensure that? The hash table has no har
Tom Lane wrote:
Jeff Davis writes:
On Mon, 2009-12-14 at 14:23 -0500, Tom Lane wrote:
I'd prefer not to leave it to the user to decide whether a type is
discrete or not.
I don't know how we can decide such a thing. Do you have any ideas?
If the only interesting use-cases are ints and enum
Takahiro Itagaki wrote:
Heavily cleaned up patch attached. Please review it.
This is almost there. The refactoring work you both did is exactly how
I was hoping this would end up looking, code-wise, and the feature set
is basically feature complete except for one small UI concern I have.
Scott Bailey writes:
> I was referring to the syntax for how the user actually defined an enum
> not about it's implementation. Basically what I was hoping to get out of
> this thread was whether it was better to allow the user to define their
> own range types by specifying the base type and p
Simon Riggs writes:
> On Mon, 2009-12-14 at 20:32 +0200, Heikki Linnakangas wrote:
>>> I have ensured that they are always the same size, by definition, so no
>>> need to check.
>>
>> How did you ensure that? The hash table has no hard size limit.
> The hash table is in shared memory and the ent
> Right, I don't think strings are any more or less countable than integers.
> (and yes, it's a bit OT).
Well, if I remember my algebra, I think the issue is that integers are
locally finite whereas strings are not ( assuming standard orderings,
of course ).
-Nathan
--
Sent via pgsql-hackers ma
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> and I would also expect there to be a nonzero performance hit
> Tom> from the extra TargetEntry expression nodes, even when the
> Tom> feature is not in use.
> I tested for that and couldn't reliably detect any (certainly <2%
> on count
Andrew Dunstan writes:
> Surely the issue from our POV is whether, given two distinct members of
> a class, we can ever say there is not any intervening member of the
> class according to some ordering. If we can't then next() and prior()
> make no sense for that class.
We would also like to b
Bernd Helmle píše v po 14. 12. 2009 v 20:42 +0100:
>
> --On 14. Dezember 2009 20:33:12 +0100 Bernd Helmle
> wrote:
>
> >> Since the author has pretty much admitted he didn't fix any of the
> >> issues that were raised by the last committer review, I'm a little
> >> confused about why you're ask
Jeff Davis writes:
> On Mon, 2009-12-14 at 14:23 -0500, Tom Lane wrote:
>> I'd prefer not to leave it to the user to decide whether a type is
>> discrete or not.
> I don't know how we can decide such a thing. Do you have any ideas?
If the only interesting use-cases are ints and enums, maybe we
Tom Lane wrote:
We can ask the user to provide a prior() and next() function, and if
they aren't provided, we assume it's continuous.
Well, that still leaves us with the problem that Joe Schmo will file
a bug when "create function next(float4) returns float4 as
$$ select $1 + 0.1 $$"
--On 14. Dezember 2009 20:33:12 +0100 Bernd Helmle
wrote:
Since the author has pretty much admitted he didn't fix any of the
issues that were raised by the last committer review, I'm a little
confused about why you're asking for another one.
It wasn't clear to me what Zdenek meant with "I
On Mon, 2009-12-14 at 14:23 -0500, Tom Lane wrote:
> > We can ask the user to provide a prior() and next() function, and if
> > they aren't provided, we assume it's continuous.
>
> Well, that still leaves us with the problem that Joe Schmo will file
> a bug when "create function next(float4) retur
On Mon, Dec 14, 2009 at 2:23 PM, Tom Lane wrote:
> It's been too long since college math classes for me to be sure whether
> "discrete" is really the exact term here. But I'm even more suspicious
> of "countable". I think a suitable diagonalization argument might show
> that strings are countabl
--On 14. Dezember 2009 07:49:34 -0500 Robert Haas
wrote:
Since the author has pretty much admitted he didn't fix any of the
issues that were raised by the last committer review, I'm a little
confused about why you're asking for another one.
It wasn't clear to me what Zdenek meant with "If
On Mon, 2009-12-14 at 11:10 -0800, Scott Bailey wrote:
> I was referring to the syntax for how the user actually defined an enum
> not about it's implementation. Basically what I was hoping to get out of
> this thread was whether it was better to allow the user to define their
> own range types
Jeff Davis writes:
> On Mon, 2009-12-14 at 13:32 -0500, Tom Lane wrote:
>> The main question I would have is how to tell whether the underlying
>> type is really discrete.
> We can ask the user to provide a prior() and next() function, and if
> they aren't provided, we assume it's continuous.
We
On Mon, 2009-12-14 at 14:14 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2009-12-14 at 13:48 -0500, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> * Disallow clustering system relations. This will definitely NOT work
> >>> * for shared relations (we have no way to update pg_class row
On Mon, 2009-12-14 at 13:32 -0500, Tom Lane wrote:
> Well, if the intention is to invent two different kinds of ranges, with
> different operators, for continuous and discrete data types, then fine.
Originally I thought most of the use cases were workable as discrete
ranges. If people want continu
Simon Riggs writes:
> On Mon, 2009-12-14 at 13:48 -0500, Tom Lane wrote:
>> Simon Riggs writes:
>>> * Disallow clustering system relations. This will definitely NOT work
>>> * for shared relations (we have no way to update pg_class rows in other
>>> * databases), nor for nailed-in-cache relation
Tom Lane wrote:
> Heikki Linnakangas writes:
>> BTW, something that's been bothering me a bit with this patch is that we
>> now have to link the backend with libpq. I don't see an immediate
>> problem with that, but I'm not a packager. Does anyone see a problem
>> with that?
>
> Yeah, I have a pr
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Yeah, I have a problem with that. What's the backend doing with libpq?
>> It's not receiving this data, it's sending it.
> walreceiver is a postmaster subprocess too.
Hm. Perhaps it should be a loadable plugin and not hard-linked into the
backend
Tom Lane wrote:
Scott Bailey writes:
So basically I have an anyrange pseudo type with the functions prev,
next, last, etc defined. So instead of hard coding range types, we would
allow the user to define their own range types. Basically if we are able
to determine the previous and next values
On Mon, 2009-12-14 at 13:48 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > * Disallow clustering system relations. This will definitely NOT work
> > * for shared relations (we have no way to update pg_class rows in other
> > * databases), nor for nailed-in-cache relations (the relfilenode va
Heikki Linnakangas writes:
> It's going to be a bit more complicated in walsender/walreceiver to work
> with the libpq COPY API. We're going to need a WAL sending/receiving
> protocol on top of it, defined in terms of rows and columns passed
> through the COPY protocol.
AFAIR, libpq knows essenti
On Mon, 2009-12-14 at 20:32 +0200, Heikki Linnakangas wrote:
> >> * You removed this comment from KnownAssignedXidsInit:
> >>
> >> - /*
> >> -* XXX: We should check that we don't exceed maxKnownAssignedXids.
> >> -* Even though the hash table might hold a few more entries than that,
> >>
Tom Lane wrote:
Scott Bailey writes:
Because intervals (mathematical not SQL) can be open or closed at each
end point we need to know what the next an previous value would be at
the specified granularity. And while you can do some operations without
knowing this, there are many you can't. For
I wrote:
> On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
> > There was considerable debate earlier about whether we wanted to treat
> > Python 3 as a separate PL so it could be available in parallel with
> > plpython 2, because of the user-level coding incompatibilities. It
> > looks like thi
Simon Riggs writes:
> * Disallow clustering system relations. This will definitely NOT work
> * for shared relations (we have no way to update pg_class rows in other
> * databases), nor for nailed-in-cache relations (the relfilenode values
> * for those are hardwired, see relcache.c). It mig
On Mon, Dec 14, 2009 at 1:42 PM, Peter Eisentraut wrote:
> I wrote:
>> On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
>> > There was considerable debate earlier about whether we wanted to treat
>> > Python 3 as a separate PL so it could be available in parallel with
>> > plpython 2, because of
Tom Lane wrote:
> The very, very large practical problem with this is that if you decide
> to change the behavior at any time, the only way to be sure that the WAL
> receiver is using the right libpq version is to perform a soname major
> version bump. The transformations done by libpq will essent
> "Tom" == Tom Lane writes:
>> Updated version of the aggregate order by patch.
Tom> I'm starting to look at this now. I find it rather bizarre to
Tom> merge both the actual arguments of an aggregate and the optional
Tom> ORDER BY expressions into a single targetlist. It doesn't seem
I wrote:
> On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
> > There was considerable debate earlier about whether we wanted to treat
> > Python 3 as a separate PL so it could be available in parallel with
> > plpython 2, because of the user-level coding incompatibilities. It
> > looks like thi
On Sun, 2009-12-13 at 22:25 +, Simon Riggs wrote:
> * Which exact tables are we talking about: just pg_class and the shared
> catalogs? Everything else is in pg_class, so if we can find it we're OK?
> formrdesc() tells me the list of nailed relations is: pg_database,
> pg_class, pg_attribute,
On Mon, 2009-12-14 at 18:02 +, Greg Stark wrote:
> >> It doesn't seem any more wrong than using hash indexes right after
> >> recovery, crash recovery or otherwise. It's certainly broken, but I
> >> don't see much value in a partial fix. The bottom line is that hash
> >> indexes should be WAL-l
Simon Riggs wrote:
> On Mon, 2009-12-14 at 11:54 +0200, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>> * Are you planning to remove the recovery_connections setting before
>> release? The documentation makes it sound like it's a temporary hack
>> that we're not really sure is needed at all. Tha
Jeff Davis writes:
> On Mon, 2009-12-14 at 11:25 -0500, Tom Lane wrote:
>> This statement seems to me to demonstrate that you don't actually
>> understand the concept of open and closed ranges.
> Of course you can still define the obvious "contains" and "overlaps"
> operators for a continuous ran
Jeff Davis wrote:
> So there are certainly some user-visible API differences between the
> two, and I don't think those differences can be hidden.
ISTM you are saying we should have two types of range types.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The Post
On Mon, 2009-12-14 at 10:00 -0800, Nathan Boley wrote:
> IMHO the first question is whether, for integers, [1,2] UNION [3,5]
> should be equal to [1,5]. In math this is certainly true, and defining
> 'next' seems like a reasonable way to establish this in postgres.
[ you say "yes" ]
Agreed.
> Th
Nathan Boley writes:
>> This statement seems to me to demonstrate that you don't actually
>> understand the concept of open and closed ranges.
> IMHO the first question is whether, for integers, [1,2] UNION [3,5]
> should be equal to [1,5]. In math this is certainly true, and defining
> 'next' se
On Mon, 2009-12-14 at 09:58 -0500, Tom Lane wrote:
> In particular, the granularity examples you give seem to assume that
> the underlying datatype is exact not approximate --- which among other
> things will mean that it fails to work for float timestamps. Since
> timestamps are supposedly the ma
Greg Smith wrote:
> Heikki Linnakangas wrote:
>> I note that if it was easy to run pgindent yourself on a patch before
>> committing/submitting, we wouldn't need to have this discussion. I don't
>> know hard it is to get it working right, but I recall I tried once and
>> gave up.
>>
> What sort
On Mon, 2009-12-14 at 11:25 -0500, Tom Lane wrote:
> Scott Bailey writes:
> > Because intervals (mathematical not SQL) can be open or closed at each
> > end point we need to know what the next an previous value would be at
> > the specified granularity. And while you can do some operations witho
Andrew Gierth writes:
> Updated version of the aggregate order by patch.
I'm starting to look at this now. I find it rather bizarre to merge
both the actual arguments of an aggregate and the optional ORDER BY
expressions into a single targetlist. It doesn't seem like that would
be an especially
On Mon, Dec 14, 2009 at 11:07 AM, Simon Riggs wrote:
>> * vacuum_defer_cleanup_age is very hard to tune. You'll need an estimate
>> on your transaction rate to begin with. Do we really want this setting
>> in its current form? Does it make sense as PGC_USERSET, as if one
>> backend uses a lower se
>> Because intervals (mathematical not SQL) can be open or closed at each
>> end point we need to know what the next an previous value would be at
>> the specified granularity. And while you can do some operations without
>> knowing this, there are many you can't. For instance you could not tell
>>
On Mon, Dec 14, 2009 at 12:38 PM, Greg Smith wrote:
> Robert Haas wrote:
>> I don't think there should be a transition from Returned with Feedback
>> back to Waiting for review. Granted we might allow that occasionally
>> as an exceptional case, but normally Returned with Feedback is a final
>> s
Robert Haas wrote:
I don't think there should be a transition from Returned with Feedback
back to Waiting for review. Granted we might allow that occasionally
as an exceptional case, but normally Returned with Feedback is a final
state.
I did throw some disclaimers in the notes about this par
On Mon, Dec 14, 2009 at 12:01 PM, Greg Smith wrote:
> Kevin Grittner wrote:
>
> http://wiki.postgresql.org/wiki/Running_a_CommitFest
>
>
>
> It seems to me that a patch could move from "Discussing review" to
> "Needs review" -- if the reviewer decided to discuss the approach
> before continuing th
Heikki Linnakangas wrote:
I note that if it was easy to run pgindent yourself on a patch before
committing/submitting, we wouldn't need to have this discussion. I don't
know hard it is to get it working right, but I recall I tried once and
gave up.
What sort of problems did you run into?
--
Kevin Grittner wrote:
http://wiki.postgresql.org/wiki/Running_a_CommitFest
It seems to me that a patch could move from "Discussing review" to
"Needs review" -- if the reviewer decided to discuss the approach
before continuing the review process and the discussion confirms the
approach as
Fred Janon wrote:
Sorry if if's a double post, but I thought that it would be more
likely I would get an answer on the hackers list.
In that case just posting here would have been better than hitting
both. I usually ignore any request for help that is posted on more than
one list just to draw
Scott Bailey writes:
> Because intervals (mathematical not SQL) can be open or closed at each
> end point we need to know what the next an previous value would be at
> the specified granularity. And while you can do some operations without
> knowing this, there are many you can't. For instance
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs wrote:
> >> Why is (1) important, and if it is important, why is it being mentioned
> >> only now? Are we saying that all previous reviewers of my work (and
> >> others') removed these without ever mentioning t
Martijn van Oosterhout wrote:
On Sun, Dec 13, 2009 at 11:49:53PM -0800, Scott Bailey wrote:
So basically I have an anyrange pseudo type with the functions prev,
next, last, etc defined. So instead of hard coding range types, we would
allow the user to define their own range types. Basically i
Simon Riggs writes:
> I definitely wouldn't presume that anybody using Hot Standby would
> necessarily want NOTIFY to reach the standby, especially if there was an
> overhead to doing so. If using NOTIFY is the favoured approach, I would
> add a separate parameter for it and/or an explicit option
Fujii Masao writes:
> I'm going to set the new function calling ereport as the current notice
> processor by using PQsetNoticeProcessor. But the problem is that only the
> completed message like "NOTICE: xxx" is passed to such notice processor,
> i.e., the error level itself is not passed.
Use PQ
On Mon, Dec 14, 2009 at 10:49 AM, Simon Riggs wrote:
> On Mon, 2009-12-14 at 09:14 -0600, Kevin Grittner wrote:
>> Simon Riggs wrote:
>>
>> > If we are going to run pgindent anyway, what is the point?
>>
>> Perhaps it would take less time to run this than to argue the point?:
>>
>> sed -e 's/[ \t
On Mon, Dec 14, 2009 at 11:09:49AM +0100, Magnus Hagander wrote:
> On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
> wrote:
> > * Please remove any spurious whitespace. "git diff --color" makes
> > them stand out like a sore thumb, in red. (pgindent will fix them
> > but always better to fix th
On Mon, 2009-12-14 at 09:14 -0600, Kevin Grittner wrote:
> Simon Riggs wrote:
>
> > If we are going to run pgindent anyway, what is the point?
>
> Perhaps it would take less time to run this than to argue the point?:
>
> sed -e 's/[ \t][ \t]*$//' -e 's/ *\t/\t/g' *
Not certain that is exac
Greg Smith wrote:
> I didn't really get any feedback on my proposal to add a new
> "Discussing review" state
It seems like a good idea to me; it better models the reality.
> http://wiki.postgresql.org/wiki/Running_a_CommitFest
It seems to me that a patch could move from "Discussing review"
Simon Riggs wrote:
> On Mon, 2009-12-14 at 11:09 +0100, Magnus Hagander wrote:
>> On Mon, Dec 14, 2009 at 10:54, Heikki Linnakangas
>> wrote:
>>> * Please remove any spurious whitespace. "git diff --color" makes them
>>> stand out like a sore thumb, in red. (pgindent will fix them but always
>>>
Tom Lane escribió:
> The whole thing would be a lot easier if someone would put together an
> easily-installable version of pgindent. Bruce has posted the patches he
> uses but I don't know what version of indent they're against...
And we're still unclear on the typedef list that's going to be u
On Mon, Dec 14, 2009 at 10:08 AM, Simon Riggs wrote:
> On Mon, 2009-12-14 at 09:32 -0500, Robert Haas wrote:
>> If every patch perfectly matched the pgident style, then the pgindent
>> run would change nothing and we would all be VERY happy.
>
> I've made all whitespace changes to the patch.
>
> I
Robert Haas writes:
> On Mon, Dec 14, 2009 at 6:35 AM, Simon Riggs wrote:
>> Why is (1) important, and if it is important, why is it being mentioned
>> only now? Are we saying that all previous reviewers of my work (and
>> others') removed these without ever mentioning they had done so?
> pgiden
On Mon, 2009-12-14 at 09:51 -0500, Tom Lane wrote:
> Greg Stark writes:
> > What happens on the slave when normal NOTIFYs are generated on the
> > master? IIRC NOTIFYs are wal-logged so I imagine LISTEN on the slave
> > would just work and a plain old NOTIFY/LISTEN would suffice for this
> > use c
Robert Haas writes:
> On Mon, Dec 14, 2009 at 4:06 AM, wrote:
>>> As another approach, what about storing typeid in typmod?
>>> (Oid can be assumed to be stored in int32.)
> It 's very different than the way we've traditionally used typmod,
Aside from the problems already pointed out, there's
On Mon, 2009-12-14 at 13:56 +0100, Magnus Hagander wrote:
> Same issue can be it in git - did you do a "git pull" before? You may
> need merging with what's on there, and for that to work you must pull
> before you can push.
Found some merge conflicts and resolved them. I did fetch and merge at
d
Simon Riggs wrote:
> If we are going to run pgindent anyway, what is the point?
Perhaps it would take less time to run this than to argue the point?:
sed -e 's/[ \t][ \t]*$//' -e 's/ *\t/\t/g' *
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Mon, 2009-12-14 at 09:32 -0500, Robert Haas wrote:
> If every patch perfectly matched the pgident style, then the pgindent
> run would change nothing and we would all be VERY happy.
I've made all whitespace changes to the patch.
I understand the reason for acting as you suggest, but we either
On Mon, 2009-12-14 at 09:51 -0500, Tom Lane wrote:
> This might be
> an example of a case where we need that "are we doing HS" flag that
> Simon insists we don't need.
Simon has put it there at your request, in the place you suggested.
Others did speak against it, not me.
--
Simon Riggs
KaiGai Kohei writes:
> One more issue I found.
> What row-level policy should be applied on inherited tables?
Yup, that seems like an interesting problem.
> Even if the inherited table has multiple parents, all the row-level
> policies shall be applied, so here is no inconsistency.
> (Needless t
1 - 100 of 151 matches
Mail list logo
