> "Hitoshi" == Hitoshi Harada writes:
Hitoshi> Hi, During reviewing aggregates ORDER BY, I was reading spec
Hitoshi> and found description like:
Hitoshi> == snip ==
Hitoshi> Of the rows in the aggregation, the following do not qualify:
Hitoshi> — If DISTINCT is specified, then redundan
I've put together a small patch to provide a schema name in an fk
violation in deference to the todo item "Report the schema along table
name in a referential failure error message"
The error message only contains the schema if the table name being
referenced is non-unique or not present in the se
2009/11/15 Andrew Gierth :
> My thinking is that the executor definitely shouldn't be relying on it
> being a specific node type, but should just ExecEvalExpr it on the
> first call and store the result; then you don't have to know whether
> it's a Const or Param node or a more complex expression.
> "Hitoshi" == Hitoshi Harada writes:
>>> (A question here: the spec allows (by my reading) the use of
>>> parameters in the window frame clause, i.e. BETWEEN $1 PRECEDING
>>> AND $2 FOLLOWING. Wouldn't it therefore make more sense to treat
>>> the values as Exprs, albeit very limited on
Hi,
During reviewing aggregates ORDER BY, I was reading spec and found
description like:
== snip ==
Of the rows in the aggregation, the following do not qualify:
— If DISTINCT is specified, then redundant duplicates.
— Every row in which the evaluates to the null value.
== /snip ==
... and ar
Thanks for your review.
2009/11/15 Andrew Gierth :
> Hi, I've started reviewing your patch.
>
> I've already found some things that need work:
>
> - missing _readWindowFrameDef function (all nodes that are output
> from parse analysis must have both _read and _out functions,
> otherwise views
2009/11/15 Tom Lane :
> Andrew Gierth writes:
>> (A question here: the spec allows (by my reading) the use of
>> parameters in the window frame clause, i.e. BETWEEN $1 PRECEDING AND
>> $2 FOLLOWING. Wouldn't it therefore make more sense to treat the
>> values as Exprs, albeit very limited ones, a
2009/11/14 Merlin Moncure :
> On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane wrote:
>> This might look neat but I don't think it's actually useful for any
>> production application. We'd need to find some way of expressing it
>> that allows caching of the expression plans. But really I think the
>> e
KaiGai Kohei wrote:
> Itagaki Takahiro wrote:
>> Here is a updated TRIGGER with WHEN cluase patch.
>> I adjusted it to work with recent parser cleanup (*OLD* and *NEW*).
>
> I would like to volunteer for reviewing the patch in RR-stage.
> It seems to me an interesting feature.
It seems to me you
On Sat, 2009-11-14 at 19:25 -0500, Tom Lane wrote:
> As a rule of thumb, I'd recommend keeping as much complexity as possible
> *out* of gram.y. It's best if that code just reports the facts, ie what
> options the user entered. Deriving conclusions from that (like what
> default behaviors should
On Sat, Nov 14, 2009 at 6:36 PM, Tom Lane wrote:
> I'm not really convinced of that, but even if we do, so what? It's not
> that much code to have an extra cache watching the syscache traffic.
> There's an example in parse_oper.c of a specialized cache that's about
> as complicated as this would
2009/11/10 Joshua Tolley :
> Ok, updated patch attached. As far as I know, this completes all outstanding
> issues:
>
Hi Joshua,
I'm taking a look at this patch for the commitfest. I see that Andrew
has already taken an interest in the technical aspects of the patch,
so I'll focus on submission/
On Sat, Nov 14, 2009 at 01:31:29PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > The side effect from this change is that some of the testsuite
> > expected data will need updating due to the extra pad spaces
>
> No, we are *not* doing that. Somebody made a change to the print.c
> logic last
Jeff Davis writes:
> 3. Some options are being set in vacuum() itself. It looks like the
> options should already be set in gram.y, so should that be an Assert
> instead? I think it's cleaner to set all of the options properly early
> on, rather than waiting until vacuum() to interpret the combina
On Tue, 2009-10-27 at 13:55 +0900, Itagaki Takahiro wrote:
> Here is a patch to support "rewrite" version of VACUUM FULL.
Can you please provide a patch that applies cleanly on top of the vacuum
options patch and on top of CVS HEAD (there are a couple minor conflicts
with this version). That would
Robert Haas writes:
> I can tell I've lost this argument, but I still don't get it. Why do
> we care if we have to change the schema? It's not a lot of work,
Try doing it a few times. Don't forget to keep psql and pg_dump
apprised of which PG versions contain which columns. Not to mention
oth
On Fri, 2009-11-13 at 10:47 +0900, Itagaki Takahiro wrote:
> Alvaro Herrera wrote:
>
> > BTW I think the vacstmt.options change, which seems a reasonable idea to
> > me, could be extracted from the patch and applied separately. That'd
> > reduce the size of the patch somewhat.
>
> It's a good i
On Sat, Nov 14, 2009 at 4:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> pg_tablespace, on the other hand, only contains one
>> type of object: a tablespace. So, if we stored the options as text[],
>> we'd parse them out into a C struct just as we do for pg_class, but
>> unlike the pg_cla
Jan Urbański wrote:
> Emmanuel Cecchet wrote:
>> Hi all,
>
> Hi!,
>
>> partitioning option for COPY
> Attached are 3 files that demonstrate problems the patch has.
And the click-before-you-think prize winner is... me.
Test cases attached, see the comments for expected/actual results.
Jan
-- s
Emmanuel Cecchet wrote:
> Hi all,
Hi!,
> partitioning option for COPY
Here's the review:
== Submission ==
The patch is contextual, applies cleanly to current HEAD, compiles fine.
The docs build cleanly.
== Docs ==
They're reasonably clear, although they still mention ERROR_LOGGING,
which was t
Jeff Davis writes:
> I'd like to try to summarize the goals we have for VACUUM to put these
> patches in perspective:
Good summary, but ...
> Some other ideas also came out of the thread, like:
> * Provide a way to truncate the dead space from the end of a relation in
> a blocking manner. Right
On Fri, Nov 13, 2009 at 11:08 AM, Tom Lane wrote:
(By the way, has anyone yet tried to
> compare the speed of this implementation to the old code?)
I quickly hacked pgbench to take a custom script on connection (for
listen), and make pgbench'd 'notify x'; with all clients doing 'listen
x'.
The
Robert Haas writes:
> pg_tablespace, on the other hand, only contains one
> type of object: a tablespace. So, if we stored the options as text[],
> we'd parse them out into a C struct just as we do for pg_class, but
> unlike the pg_class case, it would always be the *same* C struct.
The sa
2009/11/14 Merlin Moncure :
> On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane wrote:
>> This might look neat but I don't think it's actually useful for any
>> production application. We'd need to find some way of expressing it
>> that allows caching of the expression plans. But really I think the
>> e
On Fri, 2009-11-13 at 10:47 +0900, Itagaki Takahiro wrote:
> Alvaro Herrera wrote:
>
> > BTW I think the vacstmt.options change, which seems a reasonable idea to
> > me, could be extracted from the patch and applied separately. That'd
> > reduce the size of the patch somewhat.
>
> It's a good i
On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane wrote:
> This might look neat but I don't think it's actually useful for any
> production application. We'd need to find some way of expressing it
> that allows caching of the expression plans. But really I think the
> entire approach is pretty much back
On Sat, 2009-11-14 at 14:59 +0200, Heikki Linnakangas wrote:
> There's a race condition
Yes, I believe this is a major showstopper for the current
approach/attemptbut...
> I can't see any obvious way around that.
Huh? We're only doing this strict locking approach because you insisted
t
On Sat, Nov 14, 2009 at 3:06 PM, Greg Stark wrote:
> On Sat, Nov 14, 2009 at 7:28 PM, Robert Haas wrote:
>> I ended up not reusing the reloptions.c code. It looks like a lot of
>> extra complexity for no obvious benefit, considering that there is no
>> equivalent of AMs for tablespaces and there
Andrew Gierth writes:
> (A question here: the spec allows (by my reading) the use of
> parameters in the window frame clause, i.e. BETWEEN $1 PRECEDING AND
> $2 FOLLOWING. Wouldn't it therefore make more sense to treat the
> values as Exprs, albeit very limited ones, and eval them at startup
> ra
Hi, I've started reviewing your patch.
I've already found some things that need work:
- missing _readWindowFrameDef function (all nodes that are output
from parse analysis must have both _read and _out functions,
otherwise views can't work)
- the A_Const nodes should probably be transfor
"Florian G. Pflug" writes:
> Still, doing that SELECT seems rather silly since NEW and OLD already
> contain the required information. So I still believe that having
> something like record_name() and record_types() would be useful. And at
> least these functions have less of an issue with the typ
Andrew Dunstan writes:
> Tom Lane wrote:
>>> Perhaps it would help if we looked at some specific use-cases that
>>> people need, rather than debating abstractly. What do you need your
>>> generic trigger to *do*?
> One case I have is a custom audit package that ignores certain fields
> when log
Bruce Momjian wrote:
I am probably more able than most to adjust my schedule to devote time
to committing things.
Yes, time is what has restricted what I can do. I'll try to do a bit
more for this coming commitfest, but I'm rather sad that I haven't made
a more substantial contribution
Tom Lane wrote:
"Florian G. Pflug" writes:
Tom Lane wrote:
Perhaps it would help if we looked at some specific use-cases
that people need, rather than debating abstractly. What do you
need your generic trigger to *do*?
I need to build a global index table of all values of a certain
type to
I'm curious if anyone has tried to link postgres authentication with a
product called likewise.
Likesoft software will allow a linux/unix system to authenticate against
a windows domain. I have it working on several flavors of linux and
working on getting it tied into several samba shares. I
On Sat, Nov 14, 2009 at 7:28 PM, Robert Haas wrote:
> I ended up not reusing the reloptions.c code. It looks like a lot of
> extra complexity for no obvious benefit, considering that there is no
> equivalent of AMs for tablespaces and therefore no need to support
> AM-specific options. I did reu
"Florian G. Pflug" writes:
> Tom Lane wrote:
>> Perhaps it would help if we looked at some specific use-cases that
>> people need, rather than debating abstractly. What do you need your
>> generic trigger to *do*?
> I need to build a global index table of all values of a certain type
> togethe
On Sat, Nov 14, 2009 at 2:39 PM, Jeff Davis wrote:
> If you have a suggestion, I'll make the change. It doesn't sound too
> urgent though, to me.
Yeah, probably not.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Perhaps it would help if we looked at some specific use-cases that
people need, rather than debating abstractly. What do you need your
generic trigger to *do*?
The two things I have wanted most badly in the past are
On Mon, 2009-11-09 at 09:12 -0800, David E. Wheeler wrote:
> On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote:
>
> > Either of those names are fine with me, too. The current name is a
> > somewhat shortened version of the name "operator-based exclusion
> > constraints", so we can also just use that na
On Sat, 2009-11-14 at 14:36 -0500, Robert Haas wrote:
> I guess my point wasn't that the message was likely to be exercised,
> but rather that it isn't obvious that it's describing an error
> condition at all. If you get this message:
>
> relation "whatever" has relopxconstraints = -3
>
I prett
Tom Lane wrote:
"Florian G. Pflug" writes:
While I agree that handling arbitrary datatypes at runtime would be
nice, I really don't see how that could ever be done from within a
plpgsql procedure, unless plpgsql somehow morphs into a
dynamically typed language.
Which is not likely to happen
On Sat, 2009-11-14 at 09:11 -0800, David E. Wheeler wrote:
> On Nov 14, 2009, at 8:55 AM, Tom Lane wrote:
> > I had been manfully restraining myself from re-opening this discussion,
> > but yeah I was thinking the same thing. The original objection to using
> > just WITH was that it wasn't very cl
On Sat, Nov 14, 2009 at 1:58 PM, Greg Stark wrote:
> On Sat, Nov 14, 2009 at 6:00 PM, Jeff Davis wrote:
>> Hopefully the user never sees that message -- it's almost an Assert.
>> PostgreSQL uses elog(ERROR,...) in many places that should be
>> unreachable, but might happen due to bugs in distant
Well, I was regretting missing the deadline for this CommitFest and
then realized today was only the 14th, so I finished this up while the
kids were napping.
I ended up not reusing the reloptions.c code. It looks like a lot of
extra complexity for no obvious benefit, considering that there is no
Andrew Dunstan writes:
> Tom Lane wrote:
>> Perhaps it would help if we looked at some specific use-cases that
>> people need, rather than debating abstractly. What do you need your
>> generic trigger to *do*?
> The two things I have wanted most badly in the past are
> a) to be able to address
Tom Lane wrote:
"Florian G. Pflug" writes:
While I agree that handling arbitrary datatypes at runtime would be
nice, I really don't see how that could ever be done from within a
plpgsql procedure, unless plpgsql somehow morphs into a dynamically
typed language.
Which is not likely
On Sat, Nov 14, 2009 at 6:00 PM, Jeff Davis wrote:
> Hopefully the user never sees that message -- it's almost an Assert.
> PostgreSQL uses elog(ERROR,...) in many places that should be
> unreachable, but might happen due to bugs in distant places or
> corruption. I'm not sure the exact convention
"Florian G. Pflug" writes:
> While I agree that handling arbitrary datatypes at runtime would be
> nice, I really don't see how that could ever be done from within a
> plpgsql procedure, unless plpgsql somehow morphs into a dynamically
> typed language.
Which is not likely to happen, which is
Roger Leigh writes:
> The side effect from this change is that some of the testsuite
> expected data will need updating due to the extra pad spaces
No, we are *not* doing that. Somebody made a change to the print.c
logic last year that started adding "harmless" white space to the
last column, an
Tom Lane wrote:
Andrew Dunstan writes:
Yes, and I have used it, but it really would be nicer to have some
introspection facilities built in, especially for use in triggers.
Maybe, but the proposal at hand is spectacularly ugly --- in particular
it seems designed around the assumption that a g
Tom Lane wrote:
"Florian G. Pflug" writes:
Ok, I must be missing something. I currently fail to see how my
proposed record_value(record, name, anyelement) returns anyelement
function differs (from the type system's point of view) from
value_from_string(text, anyelement) returns anyelement whi
On Sat, Nov 14, 2009 at 05:40:24PM +, Roger Leigh wrote:
> On Mon, Nov 09, 2009 at 05:40:54PM -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Greg Stark writes:
> > > > While i agree this looks nicer I wonder what it does to things like
> > > > excel/gnumeric/ooffice auto-recognizing tab
2009/11/15 Jeff Davis :
> I know the error conventions are documented somewhere, but I completely
> forgot where. Can you please point me to the right place? I thought most
> error messages were supposed to be lower case, and detail messages were
> supposed to read like sentences.
http://www.postg
On Fri, 2009-11-13 at 23:39 -0500, Robert Haas wrote:
> [ reviewing ]
Thank you for the comments so far.
> In index_create(), the elog() where relopxconstraints < 0 should just
> complain about the value being negative, I think, rather than listing
> the value. If you just say the value is -3, i
Robert Haas writes:
> I haven't thought about this too deeply, but could we allow the "with
> =" part to be optional? And would it be a good idea?
I don't think so. We generally do not believe in defaulting operators
based on name. If there were a way to select the "standard" exclusion
operato
On Sat, Nov 14, 2009 at 12:11 PM, David E. Wheeler wrote:
> On Nov 14, 2009, at 8:55 AM, Tom Lane wrote:
>
>>> I've been meaning to comment on this syntax one more time; apologies for
>>> the bike-shedding. But I'm wondering if the "CHECK" is strictly necessary
>>> there, since the WITH seems ad
On Mon, Nov 09, 2009 at 05:40:54PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Greg Stark writes:
> > > While i agree this looks nicer I wonder what it does to things like
> > > excel/gnumeric/ooffice auto-recognizing table layouts and importing
> > > files. I'm not sure our old format was s
Andrew Dunstan writes:
> Yes, and I have used it, but it really would be nicer to have some
> introspection facilities built in, especially for use in triggers.
Maybe, but the proposal at hand is spectacularly ugly --- in particular
it seems designed around the assumption that a given trigger wi
Hi,
Attached is the latest version of this patch.
I altered rewriting a bit (I've brought the problems with the previous
approach up a couple of times before) and this version should have the
expected output in all situations. This patch doesn't allow you to use
INSERT/UPDATE/DELETE as the t
2009/11/14 Andrew Dunstan :
>
>
> Pavel Stehule wrote:
>>
>> Hello
>>
>> new hstore has a very nice interface for record field iteration
>>
>>
>
> Yes, and I have used it, but it really would be nicer to have some
> introspection facilities built in, especially for use in triggers.
I am not sure.
On Nov 14, 2009, at 8:55 AM, Tom Lane wrote:
>> I've been meaning to comment on this syntax one more time; apologies for the
>> bike-shedding. But I'm wondering if the "CHECK" is strictly necessary there,
>> since the WITH seems adequate, and there was some discussion before about
>> the CHECK
Pavel Stehule wrote:
Hello
new hstore has a very nice interface for record field iteration
Yes, and I have used it, but it really would be nicer to have some
introspection facilities built in, especially for use in triggers.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pg
Hello
new hstore has a very nice interface for record field iteration
http://okbob.blogspot.com/2009/10/dynamic-access-to-record-fields-in.html
Regards
Pavel Stehule
2009/11/13 Florian G. Pflug :
> Hi
>
> I'm currently working on a project where we need to build a global cache
> table containin
"David E. Wheeler" writes:
> On Nov 13, 2009, at 8:39 PM, Robert Haas wrote:
>> alter table foo add constraint bar exclude (a check with =, b check with =);
> I've been meaning to comment on this syntax one more time; apologies for the
> bike-shedding. But I'm wondering if the "CHECK" is strictl
On Nov 13, 2009, at 8:39 PM, Robert Haas wrote:
> alter table foo add constraint bar exclude (a check with =, b check with =);
I've been meaning to comment on this syntax one more time; apologies for the
bike-shedding. But I'm wondering if the "CHECK" is strictly necessary there,
since the WITH
Hi Simon and Heikki,
I can help set up automated basic tests for hot standby using 1+1 setups on
Amazon. I¹m already working on tests for warm standby for our commercial
Tungsten implementation and need to solve the problem of creating tests that
adapt flexibly across different replication mecha
"Florian G. Pflug" writes:
> Ok, I must be missing something. I currently fail to see how
> my proposed
>record_value(record, name, anyelement) returns anyelement
> function differs (from the type system's point of view) from
>value_from_string(text, anyelement) returns anyelement
> which
Tom Lane wrote:
"Florian G. Pflug" writes:
Tom Lane wrote:
Trying to do this in plpgsql is doomed to failure and heartache,
Well, the proposed functions at least allow for some more
flexibility in working with row types, given that you know in
advance which types you will be dealing with (b
"Kevin Grittner" writes:
> Peter Eisentraut wrote:
>> The patch is pretty straightforward,
>> but does anyone else actually want this? Comments?
> I agree that the initdb name seems odd next to the other executable
> names, but the functionality seems a little out of place to me in
> pg_ctl. Th
Peter Eisentraut wrote:
> The patch is pretty straightforward,
> but does anyone else actually want this? Comments?
I agree that the initdb name seems odd next to the other executable
names, but the functionality seems a little out of place to me in
pg_ctl. The other options all correspond (mo
Andres Freund wrote:
On Saturday 14 November 2009 01:03:33 Kevin Grittner wrote:
>> It is in context format, applies cleanly, and passes "make check".
> Unfortunately the latter is not saying much - I had a bug there and
> it was not found by the regression tests. Perhaps I should take a
> stab an
On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
> On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander wrote:
>> How about we add specific feature(s) about tihs to the commitfest
>> management tool? Like the possibility to directly link a git
>> repo/branch with the patch?
>
> So two fields, one fo
Hmm, const is also problem on solaris. dtrace generates probe.h file and
eats const. It generates following noise on solaris build:
"postgres.c", line 554: warning: argument #1 is incompatible with
prototype:
prototype: pointer to char : "../../../src/include/utils/probes.h",
line 582
I'm just seeing these kind of compiler warnings in current HEAD:
pgstat.c: In function ‘pgstat_report_activity’:
pgstat.c:2276: warning: passing argument 1 of
‘__dtrace_probe$postgresql$statement__status$v1$63686172202a’ discards
qualifiers from pointer target type
There are more of them (e.g
Peter Eisentraut píše v so 14. 11. 2009 v 10:41 +0200:
> On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote:
> > Attached patch extends pg_ctl command with init option.
> >
> > pg_ctl -D /var/lib/postgres [-s] init
> >
> > This should replace usage of initdb command which has problematic nam
Peter Eisentraut wrote:
On ons, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
Client encoding is declared in body of a file, but BOM is
in head of the file. So, we should always ignore BOM sequence
at the file head no matter what client encoding is used.
The attached patch replace BOM
There's a race condition between transaction commit and
GetRunningTransactionData(). If GetRunningTransactionData() runs between
the RecordTransactionCommit() and ProcArrayEndTransaction() calls in
CommitTransaction():
> /*
>* Here is where we really truly commit.
>*/
>
On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander wrote:
> How about we add specific feature(s) about tihs to the commitfest
> management tool? Like the possibility to directly link a git
> repo/branch with the patch?
So two fields, one for the repo URL and one for the branch name?
...Robert
--
On ons, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
> Client encoding is declared in body of a file, but BOM is
> in head of the file. So, we should always ignore BOM sequence
> at the file head no matter what client encoding is used.
>
> The attached patch replace BOM with while spaces, bu
On Sat, Nov 14, 2009 at 04:55, Craig Ringer wrote:
> (I'm not sure I should piping up here, so feel free to ignore, but
> perhaps I have something small to offer. I've been following the list
> for a while, but try to keep my mouth shut.)
Meh. All constructive input is welcome!
> On 13/11/2009
On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote:
> Attached patch extends pg_ctl command with init option.
>
> pg_ctl -D /var/lib/postgres [-s] init
>
> This should replace usage of initdb command which has problematic name
> as we already discussed several times. Initdb binary will be st
On fre, 2009-11-13 at 14:39 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On fre, 2009-11-13 at 15:05 +0100, Grzegorz Jaśkiewicz wrote:
> >> As per Tom's - yes, this laptop has LANG set to UTF8 Polish. Setting
> >> it back to EN actually makes this error go away.
>
> > The Polish locale
83 matches
Mail list logo
