I see what went wrong in my example. Unique constraints must have unique names
since they create an index. I'll try again, sorry for the noise.
--Dan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
I wanted to work on this todo item and I have a few questions about the
semantics of it. Essentially, it is not possible to have more than one relname
for a constraint, even though the comment in trigger.c says otherwise. I have
used this code to test this:
CREATE TABLE products (
Can't you disambiguate it using a column list on beings?
Sure, after I figured out what the real problem was. Maybe I'm a
dope, but when I get an error cursor pointed at an ambiguous column
reference, my thought is oh, I need to qualify that reference - not
oh, some completely unrelated
I'm going through a few files and trying to clean them up for style mostly and a
bit of refactoring. I am curious about the preferred style for a one line
comment. I see them in both of these forms and I would like to keep it
consistent.
/* a one line comment */
or
/*
* a one line comment
*/
On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
I am not sure where that view implemenation is, but I doubt its
stalled because of the rule system.
It is.
You can definitely create updatable views using rules
On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
Dan Colish wrote:
On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
You can definitely create updatable views using rules.
Sure you can
On Sun, Oct 04, 2009 at 11:42:45AM -0700, Josh Berkus wrote:
There are already patches to deal with the first, at least for the
kinds of VIEWs where this can be deduced automatically, and people are
starting to take on the second.
How would we deal with VIEWs which weren't simple enough
On Sun, Oct 04, 2009 at 03:15:10PM -0400, Andrew Dunstan wrote:
Dan Colish wrote:
When you speak of writing to a view, what do you mean exactly? Are we saying
refresh a view or update the parent tables of a view?
He means INSERT, UPDATE and DELETE operations on the view.
cheers
On Sun, Oct 04, 2009 at 08:54:56PM -0400, Alvaro Herrera wrote:
David E. Wheeler wrote:
On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
It's less about like or dislike and more about facing up to the
reality that we've got a major legacy foot-gun left over from the
experimentation of
- Forwarded message from Robert Haas robertmh...@gmail.com -
Date: Sun, 27 Sep 2009 12:52:35 -0400
From: Robert Haas robertmh...@gmail.com
To: Boszormenyi Zoltan z...@cybertec.at
Cc: Dan Colish d...@unencrypted.org, pgsql-rrreview...@postgresql.org,
Jeff Janes jeff.ja...@gmail.com
On Sat, Sep 26, 2009 at 10:45:17AM -0400, Mark Mielke wrote:
On 09/26/2009 10:04 AM, Simon Riggs wrote:
If you think there's
something useful I could do, let me know and I'll take a look.
I feel like I need a better way of unit testing new code. Some of the
code in the patch is to handle
On Fri, Sep 18, 2009 at 03:10:14PM +0900, Michael Paquier wrote:
You really should be returning a value at the point since the function
signature defines a return type. If not the function should be void,
which it cannot be in this context since it is used for boolean tests
elsewhere.
On Fri, Sep 18, 2009 at 10:21:08AM -0700, Josh Berkus wrote:
On 9/17/09 3:54 PM, Greg Smith wrote:
On Thu, 17 Sep 2009, Dan Colish wrote:
- Performance appears to be the same although I don't have a good
way for
testing this at the moment
Here's what I do to generate
On Fri, Sep 18, 2009 at 10:31:21AM -0700, Josh Berkus wrote:
Nope, but it was on the checklist and I was being thorough.
That's a good thing. I was just seeing if I needed to get involved in
performance testing.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
I always
On Thu, Sep 17, 2009 at 11:07:33AM -0400, Emmanuel Cecchet wrote:
Tom Lane wrote:
I wonder though if we couldn't simplify matters. Offhand it seems to me
that psql doesn't need to validate the command's syntax fully. All it
really needs to do is find the target filename and replace it with
On Thu, Sep 17, 2009 at 02:56:07PM -0400, Emmanuel Cecchet wrote:
Dan,
My bad, I copy/pasted the hard link in output/copy.source instead of
@abs_build...@.
Here is a complete version of the patch with the fix on output/copy.source.
Emmanuel
Hooray, that works just fine now. I guess I
On Thu, Sep 17, 2009 at 02:56:07PM -0400, Emmanuel Cecchet wrote:
Dan,
My bad, I copy/pasted the hard link in output/copy.source instead of
@abs_build...@.
Here is a complete version of the patch with the fix on output/copy.source.
Emmanuel
Emmanuel,
Thanks for getting
Hi,
I have read through the patch a few times and it looks OK. The
additions to the COPY syntax work as expected and as agreed upon
based on the thread. Below are some points from my checklist.
- Patch applies cleanly
- Included new tests and documentation
On Thu, Sep 17, 2009 at 09:56:44AM +0900, Michael Paquier wrote:
Hi all,
Sorry for my late reply.
There is no other update for this patch since the 13th of August, at least
until today. The new patch is attached
By the way I worked on the comments that Dan and Gabriel pointed out.
I added
On Thu, Sep 17, 2009 at 07:10:35PM -0400, Andrew Dunstan wrote:
Greg Smith wrote:
On Thu, 17 Sep 2009, Dan Colish wrote:
- Performance appears to be the same although I don't have a good
way for
testing this at the moment
Here's what I do to generate simple COPY performance
On Thu, Sep 17, 2009 at 07:45:45PM -0400, Andrew Dunstan wrote:
Dan Colish wrote:
CREATE TABLE
INSERT 0 10
Timing is on.
COPY 10
Time: 83.273 ms
BEGIN
Time: 0.412 ms
TRUNCATE TABLE
Time: 0.357 ms
COPY 10
Time: 140.911
On Tue, Sep 15, 2009 at 09:53:11PM -0400, Stephen Frost wrote:
Michael,
I just wanted to follow-up on your pgbench patch. The latest version
that I see is from August 13th. Is that the correct patch to be
reviewing? Do you have any other updates on it?
Thanks!
On Thu, Sep 10, 2009 at 08:23:00AM -0700, David E. Wheeler wrote:
On Sep 9, 2009, at 6:13 PM, Robert Haas wrote:
Hopefully this plan is acceptable to everyone. If not, please feel
free to reply here.
+1
And I'm available to review again, of course.
Best,
David
--
Sent via
Hi,
I've been looking through the current state of docuemtation,
including comments, with respect to the executor code and I would
like to improve upon their condition. If anyone has notes,
pseudocode, thoughts on how it all really works, or anything that
I found these docs to very helpful for understand how the backend works,
but for the executor specifically, I think following the code is best.
http://anoncvs.postgresql.org/cvsweb.cgi/~checkout~/pgsql/src/tools/backend/index.html
--
--Dan
On Tue, Aug 04, 2009 at 05:35:04PM -0300, Edson Ramiro
I am currently trying to convert an insertstmt back into a const
char *queryString, but I can't find an existing function to do this
for the life of me. I will write one if none exits, but I figured I
ask here first. Unfortunately, nodeToString is not quite right
On Tue, Aug 04, 2009 at 10:00:24PM -0400, Tom Lane wrote:
Dan Colish d...@unencrypted.org writes:
I am currently trying to convert an insertstmt back into a const
char *queryString, but I can't find an existing function to do this
for the life of me. I will write one if none
On Tue, Aug 04, 2009 at 10:55:07PM -0400, Tom Lane wrote:
Dan Colish d...@unencrypted.org writes:
On Tue, Aug 04, 2009 at 10:00:24PM -0400, Tom Lane wrote:
Hmm, you mean a Query, or a raw unanalyzed InsertStmt?
In this case, its a raw InsertStmt. I would like to pass this back
28 matches
Mail list logo
