2009/11/10 Joshua Tolley eggyk...@gmail.com:
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
On Sat, Nov 14, 2009 at 6:36 PM, Tom Lane t...@sss.pgh.pa.us 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
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 be
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 did an
2009/11/14 Merlin Moncure mmonc...@gmail.com:
On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane t...@sss.pgh.pa.us 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
2009/11/15 Tom Lane t...@sss.pgh.pa.us:
Andrew Gierth and...@tao11.riddles.org.uk 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
Thanks for your review.
2009/11/15 Andrew Gierth and...@tao11.riddles.org.uk:
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
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 value expression evaluates to the null value.
==
Hitoshi == Hitoshi Harada umi.tan...@gmail.com 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
2009/11/15 Andrew Gierth and...@tao11.riddles.org.uk:
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
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
Hitoshi == Hitoshi Harada umi.tan...@gmail.com 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
On fre, 2009-11-13 at 14:39 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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 still
On Sat, Nov 14, 2009 at 04:55, Craig Ringer cr...@postnewspapers.com.au 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
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, but it
On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander mag...@hagander.net 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
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.
*/
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
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 name
as we
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
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
On Sat, Nov 14, 2009 at 13:35, Robert Haas robertmh...@gmail.com wrote:
On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander mag...@hagander.net 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
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 and add
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
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
Florian G. Pflug f...@phlo.org 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
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
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
David E. Wheeler da...@kineticode.com 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
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 f...@phlo.org:
Hi
I'm currently working on a project where we need to build a global cache
table
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
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 keyword
2009/11/14 Andrew Dunstan and...@dunslane.net:
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
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
Andrew Dunstan and...@dunslane.net 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
On Mon, Nov 09, 2009 at 05:40:54PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Greg Stark gsst...@mit.edu 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
On Sat, Nov 14, 2009 at 12:11 PM, David E. Wheeler da...@kineticode.com 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
Robert Haas robertmh...@gmail.com 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
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, it
2009/11/15 Jeff Davis pg...@j-davis.com:
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.
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 gsst...@mit.edu writes:
While i agree this looks nicer I wonder what it does to things like
excel/gnumeric/ooffice auto-recognizing
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Roger Leigh rle...@codelibre.net 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
Florian G. Pflug f...@phlo.org 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, Nov 14, 2009 at 6:00 PM, Jeff Davis pg...@j-davis.com 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
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
Andrew Dunstan and...@dunslane.net 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
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
On Sat, Nov 14, 2009 at 1:58 PM, Greg Stark gsst...@mit.edu wrote:
On Sat, Nov 14, 2009 at 6:00 PM, Jeff Davis pg...@j-davis.com 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
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 clear
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
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 pretty much
On Sat, Nov 14, 2009 at 2:39 PM, Jeff Davis pg...@j-davis.com 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
Florian G. Pflug f...@phlo.org 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
On Sat, Nov 14, 2009 at 7:28 PM, Robert Haas robertmh...@gmail.com 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
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.
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 name. Or,
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
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
Andrew Dunstan and...@dunslane.net 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
Florian G. Pflug f...@phlo.org 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
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
Andrew Gierth and...@tao11.riddles.org.uk 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
On Sat, Nov 14, 2009 at 3:06 PM, Greg Stark gsst...@mit.edu wrote:
On Sat, Nov 14, 2009 at 7:28 PM, Robert Haas robertmh...@gmail.com 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
On Fri, 2009-11-13 at 10:47 +0900, Itagaki Takahiro wrote:
Alvaro Herrera alvhe...@commandprompt.com 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.
On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane t...@sss.pgh.pa.us 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
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
2009/11/14 Merlin Moncure mmonc...@gmail.com:
On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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*
On Fri, Nov 13, 2009 at 11:08 AM, Tom Lane t...@sss.pgh.pa.us 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
Jeff Davis pg...@j-davis.com 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
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
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
--
On Sat, Nov 14, 2009 at 4:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Fri, 2009-11-13 at 10:47 +0900, Itagaki Takahiro wrote:
Alvaro Herrera alvhe...@commandprompt.com 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.
Robert Haas robertmh...@gmail.com 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.
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
Jeff Davis pg...@j-davis.com 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
On Sat, Nov 14, 2009 at 01:31:29PM -0500, Tom Lane wrote:
Roger Leigh rle...@codelibre.net 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
83 matches
Mail list logo
