Re: [HACKERS] git: uh-oh
On Wed, Aug 18, 2010 at 08:25:45AM +0200, Michael Haggerty wrote: > So let's take the simplest example: a branch BRANCH1 is created from > trunk commit T1, then some time later another FILE1 from trunk commit T3 > is added to BRANCH1 in commit B4. How should this series of events be > represented in a git repository? > The "exclusive" possibility is to ignore the fact that some of the > content of B4 came from trunk and to pretend that FILE1 just appeared > out of nowhere in commit B4 independent of the FILE1 in TRUNK: > > T0 -- T1 -- T2 T3 -- T4TRUNK >\ > B1 -- B2 -- B3 -- B4BRANCH1 > > This is also wrong, because it doesn't reflect the true lineage of FILE1. But the "true lineage" is not stored anywhere in CVS so I don't see why you need to fabricate it for git. Sure, it would be really nice if you could, but if you can't do it reliably, you may as well not do it at all. What's the loss? Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle signature.asc Description: Digital signature
Re: [HACKERS] git: uh-oh
Tom Lane wrote: > I lack git-fu pretty completely, but I do have the CVS logs ;-). > It looks like some of these commits that are being ascribed to the > REL8_3_STABLE branch were actually only committed on HEAD. For > instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was > only in HEAD. It was back-patched a few hours later (1 Mar 3:41), > and that's also shown here, but the HEAD commit shouldn't be. > > I wonder whether the repository is completely OK and the problem > is that this webpage isn't filtering the commits correctly. Please don't panic :-) The problem is that it is *impossible* to faithfully represent a CVS or Subversion history with its ancestry information in a git repository (or AFAIK any of the DVCS repositories). The reason is that CVS fundamentally records the history of single files, and each file can have a branching history that is incompatible with those of other files. For example, in CVS, a file can be added to a branch after the branch already exists, different files can be added to a branch from multiple parent branches, and even more perverse things are allowed. The CVS history can record this mish-mash (albeit with much ambiguity). Git, on the other hand, fundamentally only records a single history that is considered to apply to the entire source tree. If a commit is created with more than one parent, git treats it as a merge and implicitly assumes that all of the contents of all of the ancestor commits of all of the parents have been merged into the new version of the source tree. See [1] for more discussion of the impedance mismatch between the branching model of CVS/Subversion vs. that of the DVCSs. So let's take the simplest example: a branch BRANCH1 is created from trunk commit T1, then some time later another FILE1 from trunk commit T3 is added to BRANCH1 in commit B4. How should this series of events be represented in a git repository? The "inclusive" possibility is to say that some content was merged from trunk to BRANCH1, and therefore to treat B4 as a merge commit: T0 -- T1 -- T2 T3 -- T4TRUNK \ \ B1 -- B2 -- B3 -- B4BRANCH1 This is wrong because there might be other changes in T2 and T3 (besides the addition of FILE1) that were *not* merged to BRANCH1. The "exclusive" possibility is to ignore the fact that some of the content of B4 came from trunk and to pretend that FILE1 just appeared out of nowhere in commit B4 independent of the FILE1 in TRUNK: T0 -- T1 -- T2 T3 -- T4TRUNK \ B1 -- B2 -- B3 -- B4BRANCH1 This is also wrong, because it doesn't reflect the true lineage of FILE1. Given the choice between two wrong histories, cvs2git uses the "inclusive" style. The result is that the ancestors of B4 include not only T0, T1, B1, B2, and B3 (as might be expected), but also T2 and T3. The display in the website that was quoted [2] seems to mash all of the ancestors together without showing the topology of the history, making the result quite confusing. The true history looks more like this: $ git log --oneline --graph REL8_3_10 master [...] | * 2a91f07 tag 8.3.10 | * eb1b49f Preliminary release notes for releases 8.4.3, 8.3 | * dcf9673 Use SvROK(sv) rather than directly checking SvTYP | * 1194fb9 Update time zone data files to tzdata release 201 | * fdfd1ec Return proper exit code (3) from psql when ON_ERR | * 77524a1 Backport fix from HEAD that makes ecpglib give th | * 55391af Add missing space in example. | * 982aa23 Require hostname to be set when using GSSAPI auth | * cb58615 Update time zone data files to tzdata release 201 | * ebe1e29 When reading pg_hba.conf and similar files, do no | * 5a401e6 Fix a couple of places that would loop forever if | * 5537492 Make contrib/xml2 use core xml.c's error handler, | * c720f38 Export xml.c's libxml-error-handling support so t | * 42ac390 Make iconv work like other optional libraries for | * b03d523 pgindent run on xml.c in 8.3 branch, per request | * 7efcdaa Add missing library and include dir for XSLT in M | * 6ab1407 Do not run regression tests for contrib/xml2 on M | * fff18e6 Backpatch MSVC build fix for XSLT | * 7ae09ef Fix numericlocale psql option when used with a nu | * de92a3d Fix contrib/xml2 so regression test still works w | * 80f81c3 This commit was manufactured by cvs2svn to crea | |\ | |/ |/| * | a08b04f Fix contrib/xml2 so regression test still works w * | 0d69e0f It's clearly now pointless to do backwards compat * | 4ad348c Buildfarm still unhappy, so I'll bet it's EACCES * | 6e96e1b Remove xmlCleanupParser calls from contrib/xml2. * | 5b65b67 add EPERM to the list of return codes to expect f | * a4067b3 Remove xmlCleanupParser calls from contrib/xml2. | * 91b76a4 Back-patch today's memory management fixups in co | * 5e74f21 Back-patch changes of 2009-05-13 in xml.c's memor | * 043041e This commit was manufactured by cvs2svn to crea | |\ | |/ |/| * | 98cc16f Fix up memo
Re: [HACKERS] git: uh-oh
Alex Hunsaker wrote:
> On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker wrote:
>> How sure are we that its not the cvs2svn step that is screwing it up?
>
> urp, I jumped to a conclusion while skimming the cvs2git.options file
> Magnus posted. With all the references to svn and things like
> "GitRevisionRecorder('cvs2svn-tmp/git-blob.dat')". It sure sounded
> like it converts to svn first and then to git... im not sure what it
> does.
cvs2git converts directly from CVS to git. There is no intermediate SVN
step. However, given that cvs2git is built on top of cvs2svn, it is
true that some subversion terminology appears in the configuration file
and even in some of the manufactured commit messages.
Michael
the cvs2svn/cvs2git maintainer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] security label support, part.2
(2010/08/18 12:02), Robert Haas wrote: > 2010/8/17 KaiGai Kohei: >>> I dunno. None of the above makes me feel very comfortable from a >>> security perspective because I'm concerned any of the above could too >>> easily be overlooked by someone upgrading. It also doesn't really >>> address the concern that, at some point, a child table could have >>> different permissions than a parent table. If we forcibly set the >>> permissions on the child, or ERROR'd if the permissions weren't either >>> the same or empty on the child, and then ERROR'd if someone tried to >>> change the child's permissions later, I'd be happier. >>> >> I also think ERROR should be raised when user tries to assign different >> security properties on child tables from its parent. At least, I think >> it should be configurable using a guc variable. > > If C1, C2, and C3 inherit from P, it's perfectly reasonable to grant > permissions to X on C1 and C2, Y on C3, and Z on C1, C2, C3, and P. I > don't think we should disallow that. Sure, it's possible to do things > that are less sane, but if we put ourselves in the business of > removing useful functionality because it might be misused, we'll put > ourselves out of business. > Hmm. If C1, C2 and C3 are defined to store information for different categories, but shares common data structure, indeed, it is useful. > Having said that, I'm not sure that the same arguments really hold > water in the world of label based security. Suppose we have > compartmentalized security: P is a table of threats, with C1 > containing data on nukes, C2 containing data on terrorists, and C3 > containing data on foreign militaries. If we create a label for each > of these threat types, we can apply that label to the corresponding > table; but what label shall we assign P? Logically, the label for P > should be set up in such a fashion that the only people who can read P > are those who can read C1, C2, and C3 anyway, but who is to say that > such a label exists? Right. If access privileges on P implicitly allow accesses on children, the P must have a label that only allows people who can access both of the children. However, in SELinux at least, here is no guarantee that we can always find out such a label in the security policy installed. :( > Even if KaiGai's intended implementation of > SE-PostgreSQL supports construction of such a label, who is to say > that EVERY conceivable labeling system will also do so? In fact, it > seems to me that it might be far more reasonable, in a case like this, > to ignore the *parent* label and look only at each *child* label, > which to me is an argument that we should set this up so as to allow > individual users of this hook to do as they like. > It will be helpful. If we can check each children's label, no need to restrict an identical security label within a certain inheritance hierarchy. Of course, other security module may check permissions in different basic, but it seems to me characteristics. > It's also worth pointing out that the hook in ExecCheckRTPerms() does > not presuppose label-based security. It could be used to implement > some other policy altogether, which only strengthens the argument that > we can't know how the user of the hook wants to handle these cases. > If rte->requiredPerms would not be cleared, the user of the hook will be able to check access rights on the child tables, as they like. How about an idea to add a new flag in RangeTblEntry which shows where the RangeTblEntry came from, instead of clearing requiredPerms? If the flag is true, I think ExecCheckRTEPerms() can simply skip checks on the child tables. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] security label support, part.2
2010/8/17 KaiGai Kohei : >> I dunno. None of the above makes me feel very comfortable from a >> security perspective because I'm concerned any of the above could too >> easily be overlooked by someone upgrading. It also doesn't really >> address the concern that, at some point, a child table could have >> different permissions than a parent table. If we forcibly set the >> permissions on the child, or ERROR'd if the permissions weren't either >> the same or empty on the child, and then ERROR'd if someone tried to >> change the child's permissions later, I'd be happier. >> > I also think ERROR should be raised when user tries to assign different > security properties on child tables from its parent. At least, I think > it should be configurable using a guc variable. If C1, C2, and C3 inherit from P, it's perfectly reasonable to grant permissions to X on C1 and C2, Y on C3, and Z on C1, C2, C3, and P. I don't think we should disallow that. Sure, it's possible to do things that are less sane, but if we put ourselves in the business of removing useful functionality because it might be misused, we'll put ourselves out of business. Having said that, I'm not sure that the same arguments really hold water in the world of label based security. Suppose we have compartmentalized security: P is a table of threats, with C1 containing data on nukes, C2 containing data on terrorists, and C3 containing data on foreign militaries. If we create a label for each of these threat types, we can apply that label to the corresponding table; but what label shall we assign P? Logically, the label for P should be set up in such a fashion that the only people who can read P are those who can read C1, C2, and C3 anyway, but who is to say that such a label exists? Even if KaiGai's intended implementation of SE-PostgreSQL supports construction of such a label, who is to say that EVERY conceivable labeling system will also do so? In fact, it seems to me that it might be far more reasonable, in a case like this, to ignore the *parent* label and look only at each *child* label, which to me is an argument that we should set this up so as to allow individual users of this hook to do as they like. It's also worth pointing out that the hook in ExecCheckRTPerms() does not presuppose label-based security. It could be used to implement some other policy altogether, which only strengthens the argument that we can't know how the user of the hook wants to handle these cases. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] security label support, part.2
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: > I believed that table inheritance is a unique feature in PostgreSQL. It's actually not.. > Does the SQL spec really mention about whether a child table is an > independent table object, or not? The SQL spec does discuss 'subtables' and inheiritance. It also does describe some information under 'Access Rules' regarding these sub-tables (check the 'table definition' clause). I've been looking at them and trying to make some sense out of what I see. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] security label support, part.2
(2010/08/18 9:04), Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Robert Haas writes: >>> Yeah. I'm not totally sure that is sensible for a MAC environment. >>> Heck, it's arguably incorrect (though perhaps quite convenient) in a >>> DAC environment. >> >> IIRC, the reason we did it was that we decided the SQL spec requires it. >> So there's not a lot of point in debating the issue, unless you can >> convince us we misread the spec. > > I've not gone through the spec with regard to this (yet..), but I think > we need to consider the whole 'principle of least surprise' here, > regardless of what the spec says. For one thing, this isn't how older > versions of PG behaved and while I doubt anyone intended to rely on that > behavior, it makes me nervous that someone, somewhere, unintentionally > relies on it. > I believed that table inheritance is a unique feature in PostgreSQL. Does the SQL spec really mention about whether a child table is an independent table object, or not? Or, are you talking about the behavior that parent's permission also controls accesses on child tables? If so, all of us already agreed. > What I'm thinking of is something like a warning if the permissions on > the child don't match those of the parent when the relationship is > created, or maybe forcibly setting the permissions on the child (with a > NOTICE), so it's at least clear what is going on. Or perhaps, set the > permissions on the child only if it doesn't have permissions (with the > NOTICE), and issue a WARNING if the child already has permissions set. > Perhaps also a WARNING if someone changes the permissions on a child > after the relationship has been created too, but let it happen in case > someone really wants it.. > > I dunno. None of the above makes me feel very comfortable from a > security perspective because I'm concerned any of the above could too > easily be overlooked by someone upgrading. It also doesn't really > address the concern that, at some point, a child table could have > different permissions than a parent table. If we forcibly set the > permissions on the child, or ERROR'd if the permissions weren't either > the same or empty on the child, and then ERROR'd if someone tried to > change the child's permissions later, I'd be happier. > I also think ERROR should be raised when user tries to assign different security properties on child tables from its parent. At least, I think it should be configurable using a guc variable. If WARNING/NOTICE, we can easily break consistency of the permissions... > I don't really want to force people doing routine partition additions > to have to set the permissions on the child before adding it, but I > also don't want to have to figure out "are these two sets of permissions > identical", since that's not really trivial to determine. We do have > default permissions now though, so maybe requiring the permissions be > the same from the get-go is the right idea. Of course, if we change the > permissions on the child when the inheiritance relationship is created, > we'll need to update those perms every time the parents perms are > changed. > I also think it is a good idea to copy permissions from the parent when we try to define an inheritance relationship. It obviously reduces user's routine task on defining many of child tables. It seems to me a case when we provide a NOTICE to users, if permissions of child table is overwritten. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] security label support, part.2
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > Yeah. I'm not totally sure that is sensible for a MAC environment. > > Heck, it's arguably incorrect (though perhaps quite convenient) in a > > DAC environment. > > IIRC, the reason we did it was that we decided the SQL spec requires it. > So there's not a lot of point in debating the issue, unless you can > convince us we misread the spec. I've not gone through the spec with regard to this (yet..), but I think we need to consider the whole 'principle of least surprise' here, regardless of what the spec says. For one thing, this isn't how older versions of PG behaved and while I doubt anyone intended to rely on that behavior, it makes me nervous that someone, somewhere, unintentionally relies on it. What I'm thinking of is something like a warning if the permissions on the child don't match those of the parent when the relationship is created, or maybe forcibly setting the permissions on the child (with a NOTICE), so it's at least clear what is going on. Or perhaps, set the permissions on the child only if it doesn't have permissions (with the NOTICE), and issue a WARNING if the child already has permissions set. Perhaps also a WARNING if someone changes the permissions on a child after the relationship has been created too, but let it happen in case someone really wants it.. I dunno. None of the above makes me feel very comfortable from a security perspective because I'm concerned any of the above could too easily be overlooked by someone upgrading. It also doesn't really address the concern that, at some point, a child table could have different permissions than a parent table. If we forcibly set the permissions on the child, or ERROR'd if the permissions weren't either the same or empty on the child, and then ERROR'd if someone tried to change the child's permissions later, I'd be happier. I don't really want to force people doing routine partition additions to have to set the permissions on the child before adding it, but I also don't want to have to figure out "are these two sets of permissions identical", since that's not really trivial to determine. We do have default permissions now though, so maybe requiring the permissions be the same from the get-go is the right idea. Of course, if we change the permissions on the child when the inheiritance relationship is created, we'll need to update those perms every time the parents perms are changed. Just my 2c. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] security label support, part.2
(2010/08/18 3:07), Robert Haas wrote: > On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost wrote: >> No.. and I'm not sure we ever would. What we *have* done is removed >> all permissions checking on child tables when a parent is being >> queried.. > > Yeah. I'm not totally sure that is sensible for a MAC environment. > Heck, it's arguably incorrect (though perhaps quite convenient) in a > DAC environment. Anyway, I wonder if it would be sensible to try to > adjust the structure of the DAC permissions checks so enhanced > security providers can make their own decision about how to handle > this case. > As long as we handle child tables in consistent way, here is no matter for a MAC environment also. As Stephen mentioned, the question was "what is an object". So, I want child tables being either a part of parent table or an independent object from its parent. In the first case, child tables need to have same security properties (ownership, access privileges, security labels) with its parent. In the later case, we need to check permissions on child tables also when we query on the parent, but it is an old perspective now. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
On Tue, Aug 17, 2010 at 10:53 PM, Greg Stark wrote: > (Sorry for top posting and for any typos -- typing on my phone) > > In my earlier patch to do progress indicators for arbitrary SQL queries I > had envisioned a setup similar to how we handle query cancellation. Psql > could support a key like SIGINFO which would make it request an update. > Clients like pgadmin would either do that periodically or set some guc or > protocol option to request periodic updates in advance. Which is ideal for monitoring your own connection - having the info in the pg_stat_activity is also valuable for monitoring and system administration. Both would be ideal :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 01:57:02PM -0600 I heard the voice of
Alex Hunsaker, and lo! it spake thus:
> On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker wrote:
> > How sure are we that its not the cvs2svn step that is screwing it up?
>
> urp, I jumped to a conclusion while skimming the cvs2git.options
> file Magnus posted. With all the references to svn and things like
> "GitRevisionRecorder('cvs2svn-tmp/git-blob.dat')". It sure sounded
> like it converts to svn first and then to git... im not sure what
> it does.
It's not that it converts to svn, but that it's built on (/part of)
cvs2svn, so presumably a lot of the "figure out changesets and branch
membership" logic and the "get things in the shape svn wants" logic
are intertwined.
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
(Sorry for top posting and for any typos -- typing on my phone) In my earlier patch to do progress indicators for arbitrary SQL queries I had envisioned a setup similar to how we handle query cancellation. Psql could support a key like SIGINFO which would make it request an update. Clients like pgadmin would either do that periodically or set some guc or protocol option to request periodic updates in advance. greg On 17 Aug 2010 19:07, "Stephen Frost" wrote: * Alex Hunsaker (bada...@gmail.com) wrote: > On Tue, Aug 17, 2010 at 06:31, Stephen Frost
Re: [HACKERS] security label support, part.2
Robert Haas writes: > On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost wrote: >> No.. and I'm not sure we ever would. What we *have* done is removed >> all permissions checking on child tables when a parent is being >> queried.. > Yeah. I'm not totally sure that is sensible for a MAC environment. > Heck, it's arguably incorrect (though perhaps quite convenient) in a > DAC environment. IIRC, the reason we did it was that we decided the SQL spec requires it. So there's not a lot of point in debating the issue, unless you can convince us we misread the spec. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Git migration aborted
Hello! We've aborted the git migration due to the issues Robert Haas found. This means that the cvs repository is once again open for commits, and we'll just restart the whole process wen ready. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
Robert Haas writes: > It looks to me like the commit I referenced in my original email is a > manufactured merge commit that completely rewrites the tree while > asserting that it doesn't do any such thing. AFAICS, the commits in the 8.3 history *after* that point are sane; at least there's one for each actual 8.3 commit in the CVS logs. Before that point, though, the history shown for 8.3 seems to include all HEAD commits as well. The merge commit is probably cleaning up those incorrectly included HEAD commits. I concur that we gotta abort the git conversion. This looks like it might be a pretty simple bug in the converter, but we can't block Postgres development while we look for it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker wrote:
> How sure are we that its not the cvs2svn step that is screwing it up?
urp, I jumped to a conclusion while skimming the cvs2git.options file
Magnus posted. With all the references to svn and things like
"GitRevisionRecorder('cvs2svn-tmp/git-blob.dat')". It sure sounded
like it converts to svn first and then to git... im not sure what it
does.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 13:43, Robert Haas wrote: > On Tue, Aug 17, 2010 at 3:40 PM, Tom Lane wrote: >> It'd be interesting to look into the cvs2git >> source code to see exactly what causes it to add a commit message >> like that. > > I vigorously agree. How sure are we that its not the cvs2svn step that is screwing it up? I know way back when I tried to convert a cvs tree to svn it fell over horribly. Course the same was true when we went from svn to git... (due to how we organized things in svn mainly) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 21:35, David Christensen wrote: > > On Aug 17, 2010, at 2:29 PM, Magnus Hagander wrote: > >> On Tue, Aug 17, 2010 at 21:28, Robert Haas wrote: >>> On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander >>> wrote: The tip of every branch, and every single tag, all have the correct data in them, but some revisions in between seem majorly confused. >>> >>> It seems to me that what we'll need to do here is write a script to >>> look through the CVS history of each file and make sure that the >>> versions of that file which appear on each branch match the revs in >>> CVS in content, order, and the commit message associated with any >>> changes. However, that's not going to do get done today. >> >> Yeah. Unless someone comes up with a good way to fix this, or even >> better an explanation why it's actually ont broken and we're looking >> at things wrong :D, I think we have no choice but aborting the >> conversion for now and come back to it later. > > > Can you post the cvs2svn command line used for conversion? Sure: cvs2git --options=/root/cvs2git.options Attached is the options file. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ cvs2git.options Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 3:40 PM, Tom Lane wrote: > It'd be interesting to look into the cvs2git > source code to see exactly what causes it to add a commit message > like that. I vigorously agree. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
BTW, those two "manufactured" commits seem to directly follow commits into HEAD that added files that were later also added on the branch. I dunno exactly how git represents that type of event, but maybe an extra commit is needed? It'd be interesting to look into the cvs2git source code to see exactly what causes it to add a commit message like that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
* Tom Lane [100817 15:30]: > I lack git-fu pretty completely, but I do have the CVS logs ;-). > It looks like some of these commits that are being ascribed to the > REL8_3_STABLE branch were actually only committed on HEAD. For > instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was > only in HEAD. It was back-patched a few hours later (1 Mar 3:41), > and that's also shown here, but the HEAD commit shouldn't be. > > I wonder whether the repository is completely OK and the problem > is that this webpage isn't filtering the commits correctly. No, that git branch is definately strange. The commit Robert pointed out is a merge commit. But looking at your explanation of when similar commits with the same message were committed, I'm guessng the "timestamp fudge factor" along with the "look for same commit message" behaviour of Magnus's cvs2git conversion is trying "too hard" to make "atomic" commits of non-atomic commits. If you use a git viewer that shows the fork/merge points, you can see that there are lots of these little "common" commits that have been "unified" onto multiple brances. Magnus, can you check if you can reduce the time fudge? a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 3:29 PM, Tom Lane wrote: > I lack git-fu pretty completely, but I do have the CVS logs ;-). > It looks like some of these commits that are being ascribed to the > REL8_3_STABLE branch were actually only committed on HEAD. For > instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was > only in HEAD. It was back-patched a few hours later (1 Mar 3:41), > and that's also shown here, but the HEAD commit shouldn't be. It looks to me like the commit I referenced in my original email is a manufactured merge commit that completely rewrites the tree while asserting that it doesn't do any such thing. > I wonder whether the repository is completely OK and the problem > is that this webpage isn't filtering the commits correctly. No. The repository itself has the same problem, or at least my clone of it does. I have to say I am totally underwhelmed by the quality of the CVS-to-git conversion tools I've seen so far. It's fine for Linus to say that CVS will eat your data, but these tools were evidently written with grossly inadequate error and sanity checks. Whatever we've been using for the incremental conversions doesn't seem to think it's a problem if the new commit it's pushing doesn't make the head of the tree match CVS HEAD, which seeems like a pretty darn obvious thing to check for, and this tool evidently can't follow branch history properly. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
On Aug 17, 2010, at 2:29 PM, Magnus Hagander wrote: > On Tue, Aug 17, 2010 at 21:28, Robert Haas wrote: >> On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander wrote: >>> The tip of every branch, and every single tag, all have the correct >>> data in them, but some revisions in between seem majorly confused. >> >> It seems to me that what we'll need to do here is write a script to >> look through the CVS history of each file and make sure that the >> versions of that file which appear on each branch match the revs in >> CVS in content, order, and the commit message associated with any >> changes. However, that's not going to do get done today. > > Yeah. Unless someone comes up with a good way to fix this, or even > better an explanation why it's actually ont broken and we're looking > at things wrong :D, I think we have no choice but aborting the > conversion for now and come back to it later. Can you post the cvs2svn command line used for conversion? Regards, David -- David Christensen End Point Corporation da...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 21:28, Robert Haas wrote: > On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander wrote: >> The tip of every branch, and every single tag, all have the correct >> data in them, but some revisions in between seem majorly confused. > > It seems to me that what we'll need to do here is write a script to > look through the CVS history of each file and make sure that the > versions of that file which appear on each branch match the revs in > CVS in content, order, and the commit message associated with any > changes. However, that's not going to do get done today. Yeah. Unless someone comes up with a good way to fix this, or even better an explanation why it's actually ont broken and we're looking at things wrong :D, I think we have no choice but aborting the conversion for now and come back to it later. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
Magnus Hagander writes: > On Tue, Aug 17, 2010 at 21:16, Tom Lane wrote: >> Um ... Magnus has not given any report that he's finished running >> the conversion. What exactly are you looking at? > That's the previous conversion. The one that we used to verify that > things looked ok. Seems nobody caught this :S > The new migration looks similarly weird. > Does anybody with some more git-fu have any clue how this can be? I lack git-fu pretty completely, but I do have the CVS logs ;-). It looks like some of these commits that are being ascribed to the REL8_3_STABLE branch were actually only committed on HEAD. For instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was only in HEAD. It was back-patched a few hours later (1 Mar 3:41), and that's also shown here, but the HEAD commit shouldn't be. I wonder whether the repository is completely OK and the problem is that this webpage isn't filtering the commits correctly. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander wrote: > The tip of every branch, and every single tag, all have the correct > data in them, but some revisions in between seem majorly confused. It seems to me that what we'll need to do here is write a script to look through the CVS history of each file and make sure that the versions of that file which appear on each branch match the revs in CVS in content, order, and the commit message associated with any changes. However, that's not going to do get done today. >>> It's too bad that nobody noticed this sooner, but I'm glad I noticed >>> today rather than tomorrow. >> >> We're not going to start using the git repository until everyone is >> satisfied it's OK, both as to current contents and history. Duh. But obviously no one's checked that carefully enough up until now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Additional git conversion steps
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane wrote: > There are a couple of things I think should happen ASAP once the git > repository is up, but weren't mentioned in Magnus' plans: > > 1. The various .cvsignore files need to be replaced by .gitignore files. > I am not sure though whether this is a trivial conversion --- does git > have similar default rules about ignoring .o, etc? Certainly, with two variations: 1. If you don't want to hear about *.rej or *.orig files, you could put relevant patterns into $GIT_DIR/.git/info/exclude That's not checked in - that's configuration for one particular repo, and that repo alone. 2. You can create a .gitignore file in any directory, and check it in; it'll indicate patterns to ignore in this directory and those below. So, you'd presumably do something like: echo "*.o" >> $GIT_DIR/.gitignore to deal with .o files echo "*~" >> $GIT_DIR/.gitignore so Emacs deteriorata gets ignored and some other set of additions for typical "cruft" that is normally safe to ignore. The existing .cvsignore files can simply get renamed to .gitignore, and that'll just work. I had the entertaining case where, with Slony-I, I did, within the same commit: git rm .cvsignore git add .gitignore (where I had copied data from one to the other) and discovered that Git discovered that this was actually a "mv" request. I frequently find myself doing a build of things, and then running: git status > .gitignore which stows *all* the generated files, commented, so that they aren't yet ignored. Then, edit .gitignore, stripping off leading # for things that should be ignored, and drop out anything that shouldn't be ignored. git commit .gitignore -m "Populate all generated files that should be ignored by Git" This is one of the first things worth committing once Git gets turned on. -- http://linuxfinances.info/info/linuxdistributions.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 21:16, Tom Lane wrote: > Robert Haas writes: >> It appears that the git conversion of the CVS repository is seriously >> screwed up. For example, if you look at this: > > Um ... Magnus has not given any report that he's finished running > the conversion. What exactly are you looking at? That's the previous conversion. The one that we used to verify that things looked ok. Seems nobody caught this :S The new migration looks similarly weird. Does anybody with some more git-fu have any clue how this can be? The tip of every branch, and every single tag, all have the correct data in them, but some revisions in between seem majorly confused. >> It's too bad that nobody noticed this sooner, but I'm glad I noticed >> today rather than tomorrow. > > We're not going to start using the git repository until everyone is > satisfied it's OK, both as to current contents and history. Yeah.. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git: uh-oh
Robert Haas writes: > It appears that the git conversion of the CVS repository is seriously > screwed up. For example, if you look at this: Um ... Magnus has not given any report that he's finished running the conversion. What exactly are you looking at? > It's too bad that nobody noticed this sooner, but I'm glad I noticed > today rather than tomorrow. We're not going to start using the git repository until everyone is satisfied it's OK, both as to current contents and history. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] git: uh-oh
It appears that the git conversion of the CVS repository is seriously screwed up. For example, if you look at this: http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=shortlog;h=refs/tags/REL8_3_10 The first few revs look OK, but the you get to this: 2010-02-28 PostgreSQL... This commit was manufactured by cvs2svn to create branch REL8_3_STABLE Prior to that commit, this history is nonsense - it appears to be the history of our 9.0 development prior to that date. I would say we're going back to good old CVS. It's too bad that nobody noticed this sooner, but I'm glad I noticed today rather than tomorrow. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
--On 17. August 2010 20:08:51 +0200 Erik Rijkers wrote: How can I 'change OID'? This error comes out of an initial initdb run. (There are several other test-instances on this machine (several running), but with their own $PGDATA, $PGPORT. - they can't interfere with each other, can they?) I assume Peter means an OID conflict, resulting from concurrent patches or drifting code. Looks like pg_stat_get_backend_progress() has a conflict in current HEAD with xmlexists() (both will get 2614 in my current version of pg_proc.h). You need to resolve this to have initdb succeed. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Additional git conversion steps
"Kevin Grittner" writes: > I could post my .gitignore file if you like. Yeah, let's see it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] refactoring comment.c
Robert Haas writes: > On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane wrote: >> I don't insist that the separation has to be crisp. I'm merely saying >> that putting a large chunk of useful-only-at-execution-time code into >> backend/parser is the Wrong Thing. > OK, but there should be a reason for that. For example, if there are > circumstances when we parse a statement, and then time passes, and > then we execute it later, that's a good argument for what you're > saying here. Yeah, and that's exactly what happens with utility statements that (for example) get into the plan cache. > I was actually thinking of proposing that we make more things happen > during the parsing process and postpone less to the execution phase, > and I need to make sure that I understand why you don't want to do > that. The reason to not do that is that you'd have to hold more locks, and do more management of those locks, in order to protect the more-thoroughly-analyzed statements from parsing to execution. In the case of utility statements, particularly ones that affect a lot of objects, I think that would be a seriously bad idea. In fact it would fly in the face of lessons we learned the hard way. The whole of parser/parse_utilcmd.c is code that we used to execute "at parse time", and had to rearrange to postpone to execution time, in order to avoid nasty bugs. It's still in backend/parser because it fits well there and uses a lot of parser infrastructure that's shared with parse-time analysis of DML statements. But neither of those statements hold for the ObjectAddress resolution code. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Python 2.7 deprecated the PyCObject API?
On tis, 2010-08-17 at 20:55 +0300, Peter Eisentraut wrote: > On fre, 2010-08-13 at 20:20 -0400, 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 to do something about this? > > Some exception handling might be good, but I think we don't need to > abandon the API yet. It's only "pending deprecation". Here is a patch. The crash is reproducible, if warnings are turned into errors. Index: plpython.c === RCS file: /cvsroot/pgsql/src/pl/plpython/plpython.c,v retrieving revision 1.148 diff -u -3 -p -r1.148 plpython.c --- plpython.c 8 Jul 2010 19:00:11 - 1.148 +++ plpython.c 17 Aug 2010 18:45:49 - @@ -1315,6 +1315,8 @@ PLy_procedure_get(FunctionCallInfo fcinf elog(FATAL, "expected a PyCObject, didn't get one"); proc = PyCObject_AsVoidPtr(plproc); + if (!proc) + PLy_elog(ERROR, "PyCObject_AsVoidPtr() failed"); if (proc->me != plproc) elog(FATAL, "proc->me != plproc"); /* did we find an up-to-date cache entry? */ @@ -1539,8 +1541,11 @@ PLy_procedure_create(HeapTuple procTup, PLy_procedure_compile(proc, procSource); pfree(procSource); + procSource = NULL; proc->me = PyCObject_FromVoidPtr(proc, NULL); + if (!proc->me) + PLy_elog(ERROR, "PyCObject_FromVoidPtr() failed"); PyDict_SetItemString(PLy_procedure_cache, key, proc->me); } PG_CATCH(); -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Additional git conversion steps
On 18 August 2010 04:42, Tom Lane wrote: > Robert Haas writes: >> No, it doesn't. There are some policy decisions to be made here, too, >> about what we wish to actually ignore. Personally, my preference >> would be to arrange to ignore all and only *build products*, but not >> things like *.rej files that CVS "helpfully" fails to mention. > > My understanding of the point of an ignore file is to make sure that the > SCM doesn't decide to commit junk into the repository. So *.rej, and > editor backup files (*~) should be in the ignore files IMO. Things are subtly different with git. git will never "decide" to add a file to the index unless you explicitly tell it to, with `git add`. So the idea with a .gitignore file is to tune it so that when you type `git status` it only tells you about things that you might want to either a) commit, or b) clean up. With .rej files and other such items, it's nice that `git status` pipes up about them, because it reminds you to get rid of them when you're done hacking. > > Well, the per-directory files are that way because CVS insists, but > we could certainly consider alternative layouts if git can do better. > I'm not convinced that one big file is better though. Can we use a > single file at the top level for policy (*.o, *.so, etc) and additional > files lower down for specific exceptions (parser/gram.c)? You sure can! Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Additional git conversion steps
Tom Lane wrote: > Can we use a single file at the top level for policy (*.o, *.so, > etc) and additional files lower down for specific exceptions > (parser/gram.c)? Yes. Just as a start, done on a rather ad hoc basis, mine is attached. If you put that at the top, current HEAD is clean, at least for the builds I do. -Kevin .gitignore Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/pgSQL EXECUTE '..' USING with unknown
2010/8/17 Tom Lane : > =?ISO-8859-1?Q?C=E9dric_Villemain?= > writes: >> Here we are. A simple usecase. > > The reason you have an issue here is that the column is char(n) while > the parameter is text. So the non-USING execute is equivalent to > > regression=# explain SELECT flag FROM foo where uid = > 'cfcd208495d565ef66e7dff9f98764da'; > QUERY PLAN > > Index Scan using foo_pkey on foo (cost=0.00..8.27 rows=1 width=1) > Index Cond: (uid = 'cfcd208495d565ef66e7dff9f98764da'::bpchar) > (2 rows) > > while the EXECUTE USING is equivalent to > > regression=# explain SELECT flag FROM foo where uid = > 'cfcd208495d565ef66e7dff9f98764da'::text; > QUERY PLAN > > Seq Scan on foo (cost=0.00..24.02 rows=5 width=1) > Filter: ((uid)::text = 'cfcd208495d565ef66e7dff9f98764da'::text) > (2 rows) > > and the reason you don't get an indexscan on the latter is that it's a > TEXT comparison not a BPCHAR comparison; which is different because of > the rules about ignoring trailing blanks. > > char(n) sucks. Avoid it if possible. If you insist on using it, > be very very careful about which comparison semantics you're asking for. Oh! Thank you very much for those clarifications. ... and I am sorry for the noisy report ... -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Additional git conversion steps
Robert Haas writes: > On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane wrote: >> 1. The various .cvsignore files need to be replaced by .gitignore files. >> I am not sure though whether this is a trivial conversion --- does git >> have similar default rules about ignoring .o, etc? > No, it doesn't. There are some policy decisions to be made here, too, > about what we wish to actually ignore. Personally, my preference > would be to arrange to ignore all and only *build products*, but not > things like *.rej files that CVS "helpfully" fails to mention. My understanding of the point of an ignore file is to make sure that the SCM doesn't decide to commit junk into the repository. So *.rej, and editor backup files (*~) should be in the ignore files IMO. I'm not totally clear on what CVS' default list is, though. > Also, > I think we should consider having just one .gitignore file at the top > level rather than a file in every individual directory (you can > include relative pathnames). I think that might be significantly > easier to manage. Well, the per-directory files are that way because CVS insists, but we could certainly consider alternative layouts if git can do better. I'm not convinced that one big file is better though. Can we use a single file at the top level for policy (*.o, *.so, etc) and additional files lower down for specific exceptions (parser/gram.c)? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Additional git conversion steps
Tom Lane wrote: > 1. The various .cvsignore files need to be replaced by .gitignore > files. I could post my .gitignore file if you like. I'm sure it can be improved upon by others, but it gives me a clean `git status` result when it should. Probably better than nothing as a start. > * src/backend/utils/cache/plancache.c > * Plan cache management. Sounds good to me. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] refactoring comment.c
On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane wrote: >>> Rereading this, I see I didn't make my point very clearly. The reason >>> this code doesn't belong in parser/ is that there's no prospect the >>> parser itself would ever use it. ObjectAddress is an execution-time >>> creature because we don't want utility statement representations to be >>> resolved to OID-level detail before they execute. > >> Well, that is a good reason for doing it your way, but I'm slightly >> fuzzy on why we need a crisp separation between parse-time and >> execution-time. > > I don't insist that the separation has to be crisp. I'm merely saying > that putting a large chunk of useful-only-at-execution-time code into > backend/parser is the Wrong Thing. OK, but there should be a reason for that. For example, if there are circumstances when we parse a statement, and then time passes, and then we execute it later, that's a good argument for what you're saying here. But otherwise, the fact that these bits of barely-parsed stuff get passed all over the backend seems like an inconvenient wart. I was actually thinking of proposing that we make more things happen during the parsing process and postpone less to the execution phase, and I need to make sure that I understand why you don't want to do that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Additional git conversion steps
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane wrote: > There are a couple of things I think should happen ASAP once the git > repository is up, but weren't mentioned in Magnus' plans: > > 1. The various .cvsignore files need to be replaced by .gitignore files. > I am not sure though whether this is a trivial conversion --- does git > have similar default rules about ignoring .o, etc? No, it doesn't. There are some policy decisions to be made here, too, about what we wish to actually ignore. Personally, my preference would be to arrange to ignore all and only *build products*, but not things like *.rej files that CVS "helpfully" fails to mention. Also, I think we should consider having just one .gitignore file at the top level rather than a file in every individual directory (you can include relative pathnames). I think that might be significantly easier to manage. > 2. One thing I will miss from the removal of $PostgreSQL$ tags is that > they guaranteed that every file contained its own full pathname within > the source tree. I found myself using that an awful lot, mainly as a > source for copying-and-pasting file paths. To substitute for the tags, > I would like to propose a project standard that every file contain its > pathname in the header comment, not just the bare filename which is the > de facto standard at the moment. For example, instead of This seems totally useless to me. However, I suppose you can do it if it makes you happy... > Whatever we do with the .cvsignore files will need to be back-patched > into all active branches, but I am not so anal-retentive as to wish > to back-patch the pathname comment changes. Yes, we should DEFINITELY back-patch the .cvsignore stuff. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] security label support, part.2
* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost wrote: > > No.. and I'm not sure we ever would. What we *have* done is removed > > all permissions checking on child tables when a parent is being > > queried.. > > Yeah. I'm not totally sure that is sensible for a MAC environment. > Heck, it's arguably incorrect (though perhaps quite convenient) in a > DAC environment. Anyway, I wonder if it would be sensible to try to > adjust the structure of the DAC permissions checks so enhanced > security providers can make their own decision about how to handle > this case. To be honest, I don't really like the way this is done at all. I'd rather have it such that if and when a table is made a child of another table, it should inherit the permissions of the parent and be kept that way, or it should be completely independent (which is the situation we used to have), or, last resort, we should complain when they don't match. Or we could just not error when we hit a child table that the caller doesn't have access to (but also not return the records). The problem is that we've got different users that want to use inheiritance for very different purposes and we havn't got a way to address all of them. I do worry that we're going to regret making the change to not check permissions on child tables, but at the same time, any query which would have been impacted by that would have failed, so that really begs the question of "do people really use/want different permissions on child tables than the parent?". I tend to think 'no', and would rather force them and keep them the same, but maybe that's just me.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] refactoring comment.c
Robert Haas writes: > On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane wrote: >> Rereading this, I see I didn't make my point very clearly. The reason >> this code doesn't belong in parser/ is that there's no prospect the >> parser itself would ever use it. ObjectAddress is an execution-time >> creature because we don't want utility statement representations to be >> resolved to OID-level detail before they execute. > Well, that is a good reason for doing it your way, but I'm slightly > fuzzy on why we need a crisp separation between parse-time and > execution-time. I don't insist that the separation has to be crisp. I'm merely saying that putting a large chunk of useful-only-at-execution-time code into backend/parser is the Wrong Thing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Additional git conversion steps
There are a couple of things I think should happen ASAP once the git repository is up, but weren't mentioned in Magnus' plans: 1. The various .cvsignore files need to be replaced by .gitignore files. I am not sure though whether this is a trivial conversion --- does git have similar default rules about ignoring .o, etc? 2. One thing I will miss from the removal of $PostgreSQL$ tags is that they guaranteed that every file contained its own full pathname within the source tree. I found myself using that an awful lot, mainly as a source for copying-and-pasting file paths. To substitute for the tags, I would like to propose a project standard that every file contain its pathname in the header comment, not just the bare filename which is the de facto standard at the moment. For example, instead of /*- * * plancache.c *Plan cache management. we should have /*- * * src/backend/utils/cache/plancache.c *Plan cache management. Whatever we do with the .cvsignore files will need to be back-patched into all active branches, but I am not so anal-retentive as to wish to back-patch the pathname comment changes. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Writeable CTEs Desgin Doc on Wiki
On Mon, Aug 16, 2010 at 11:41 PM, Hitoshi Harada wrote: > 2010/8/17 Robert Haas : >> On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada wrote: >>> We (Marko, David Fetter and I) discussed on IRC about design of >>> writeable CTEs. It does and will contain not only syntax but also >>> miscellaneous specifications, general rules and restrictions. I hope >>> this will help the patch reviews and stop dangerous design at the >>> early stage. If you find something wrong, or have request, please >>> notify. >>> >>> http://wiki.postgresql.org/wiki/WriteableCTEs >>> >>> We will keep to add details. Any comments are welcome. >> >> There are really two separate features here, and it might be worth >> giving them separate names and separate designs (and separate >> patches). Allowing the main query to be an insert, update, or delete >> seems easier than allowing the toplevel CTEs to contain those >> constructs, although I might be wrong about that. >> >> Under features, what is DCL? There has been previous talk of allowing >> WITH (COPY ...) and I am personally of the opinion that it would be >> nice to be able to do WITH (EXPLAIN ...). DDL seems like a poor idea. > > So, there are three? One for allowing the main query to be an insert, > update, or delete, one for the main subject of writeable CTE with > insert, update, delete and one for allowing COPY to return rows. I am > attracted by such COPY functionality. Yeah, I'd say there are at least three. Maybe more than three. > And the first part seems easier to be committed separately. Is it > possible to get it in by only adding syntax and little parser/planner > modification, or more executor code? I'm not sure exactly what is involved, but it seems to me that breaking large features into moderately-sized, self-contained chunks tends to drastically shorten the time to commit. Of course, this is only true if each patch is really an independent feature with independent utility, but in this case it seems fairly easy to draw a clean line. >> P.S. Call me a prude, but your choice of shorthand for >> insert-update-delete may not be the best. > > I think so, too :(. But there's no good expression in my mind. Suggestions? DML? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
On Tue, Aug 17, 2010 at 11:54, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker wrote:
>> On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
>>> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
> /me is very sorry master. Please beat your unworthy servant only
> lightly... or alternatively, buy me a faster machine.
Well, I might be able to afford a beer.
>>>
>>> Done!
>>
>> Well on 2nd thought, maybe not... If people start collecting I'll be
>> broke (notably I owe tom quite a few :-).
>
> Cheapskate.
Its because i'm thinking of getting everyone on -hackers a pony instead!
>> Anyway find below version that passes any arguments through to git-log.
>
> Yeah, I don't think I want to go that route. Arbitrary user-specified
> arguments to git-log might not be (probably aren't) sane in this
> context, and there's also a chance that might want to have arguments
> that are handled internally by the script, rather than passed through.
Yeah, I originally was just going to do --since. After seeing how
many args git-log can have-- It looked like people might request new
args into the foreseeable future.
Find --since below FWIW:
--
--- git-topo-order (1) 2010-08-17 09:44:18.069517261 -0600
+++ git-topo-order 2010-08-17 12:10:07.312355246 -0600
@@ -26,6 +26,12 @@
use strict;
use warnings;
require Date::Calc;
+use IPC::Open2;
+use Getopt::Long;
+
+# since gets passed through to git-log
+my $since;
+GetOptions('since=s'=>\$since);
my @BRANCHES = qw(master REL9_0_STABLE REL8_4_STABLE REL8_3_STABLE
REL8_2_STABLE REL8_1_STABLE REL8_0_STABLE REL7_4_STABLE);
@@ -34,11 +40,19 @@
my %all_commits_by_branch;
my %commit;
+my %position;
for my $branch (@BRANCHES) {
my $commitnum = 0;
- open(GITLOG, "git log --date=iso origin/$branch |")
+ $position{$branch} = 0;
+
+ my @args = qw(git log --date=iso);
+ push @args, "--since=$since" if($since);
+ push @args, "origin/$branch";
+
+ open2(my $git_out, my $git_in, @args)
|| die "can't run git log origin/$branch: $!";
- while (my $line = ) {
+
+ while (my $line = <$git_out>) {
if ($line =~ /^commit\s+(.*)/) {
push_commit(\%commit) if %commit;
%commit = (
@@ -60,10 +74,6 @@
}
}
-my %position;
-for my $branch (@BRANCHES) {
- $position{$branch} = 0;
-}
while (1) {
my $best_branch;
my $best_inversions;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] refactoring comment.c
On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane wrote: > I wrote: >> Maybe so, but the parser is expected to put out a representation that >> will still be valid when the command is executed some time later. > > Rereading this, I see I didn't make my point very clearly. The reason > this code doesn't belong in parser/ is that there's no prospect the > parser itself would ever use it. ObjectAddress is an execution-time > creature because we don't want utility statement representations to be > resolved to OID-level detail before they execute. Well, that is a good reason for doing it your way, but I'm slightly fuzzy on why we need a crisp separation between parse-time and execution-time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
On Tue, August 17, 2010 19:13, Peter Eisentraut wrote: > On tis, 2010-08-17 at 15:59 +0200, Erik Rijkers wrote: >> creating template1 database in >> /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1 >> ... FATAL: could not >> create unique index "pg_proc_oid_index" >> DETAIL: Key (oid)=(2614) is duplicated. > > Probably merge conflict with parallel developments. Try changing the > OID. Could you elaborate? What is a 'merge conflict'? Or 'parallel developments'? Do you mean the current git conversion? (I get source from a local rsync'ed cvs repository) How can I 'change OID'? This error comes out of an initial initdb run. (There are several other test-instances on this machine (several running), but with their own $PGDATA, $PGPORT. - they can't interfere with each other, can they?) thanks, Erik Rijkers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] security label support, part.2
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost wrote: > No.. and I'm not sure we ever would. What we *have* done is removed > all permissions checking on child tables when a parent is being > queried.. Yeah. I'm not totally sure that is sensible for a MAC environment. Heck, it's arguably incorrect (though perhaps quite convenient) in a DAC environment. Anyway, I wonder if it would be sensible to try to adjust the structure of the DAC permissions checks so enhanced security providers can make their own decision about how to handle this case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
* Alex Hunsaker (bada...@gmail.com) wrote: > On Tue, Aug 17, 2010 at 06:31, Stephen Frost wrote: > > * Peter Eisentraut (pete...@gmx.net) wrote: > >> Other comments? > > > > Will we be able to use it for psql while keeping just one database > > connection? I assume the answer is 'no', but it sure would be nice.. > > I think thats something that could be worked out in libpq after this > patch. Although I'd bump your nice to an awesome. If it was configurable via \set and I could drop it in my .psqlrc, and it knew not to only do it after a few seconds (otherwise it'd be far too much)... I don't like how the backend would have to send something NOTICE-like, I had originally been thinking "gee, it'd be nice if psql could query pg_stat while doing something else", but that's not really possible... So, I guess NOTICE-like messages would work, if the backend could be taught to do it. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] security label support, part.2
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote: > >Stephen Frost wrote: > > > Let's not build the complication of dealing with inheiritance/ > > child relations into the external security system when we're in > > the middle of trying to get rid of that distinction in core PG > > though. > > I didn't realize we were trying to do that. I know we're working on > making partitioning easier, but there hasn't been a decision to stop > supporting other uses of inheritance, has there? No.. and I'm not sure we ever would. What we *have* done is removed all permissions checking on child tables when a parent is being queried.. Stephen signature.asc Description: Digital signature
Re: [HACKERS] security label support, part.2
>Stephen Frost wrote: > No.. and I'm not sure we ever would. What we *have* done is > removed all permissions checking on child tables when a parent is > being queried.. OK, that clarifies things. Thanks. So, essentially that means that you need to set all ancestor levels to something at least as strict as the intersection of all the permissions on lower levels to avoid exposing something through an ancestor which is restricted in a descendant. And you'd better trust the owner of any table you extend, because they can bypass any attempt to restrict access to the table you create which extends theirs. I hope those security implications are well documented. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Python 2.7 deprecated the PyCObject API?
On fre, 2010-08-13 at 20:20 -0400, 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 to do something about this? Some exception handling might be good, but I think we don't need to abandon the API yet. It's only "pending deprecation". -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker wrote: > On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote: >> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote: >>> On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote: /me is very sorry master. Please beat your unworthy servant only lightly... or alternatively, buy me a faster machine. >>> >>> Well, I might be able to afford a beer. >> >> Done! > > Well on 2nd thought, maybe not... If people start collecting I'll be > broke (notably I owe tom quite a few :-). Cheapskate. > Anyway find below version that passes any arguments through to git-log. Yeah, I don't think I want to go that route. Arbitrary user-specified arguments to git-log might not be (probably aren't) sane in this context, and there's also a chance that might want to have arguments that are handled internally by the script, rather than passed through. But I do agree that passing --since through is sensible. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
Magnus Hagander wrote: > On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane wrote: > > Robert Haas writes: > >> It should get a bit faster if we reduce the number of branches it > >> examines, which I assume is something we can do once we desupport 7.4 > >> and 8.0. ?We could also add a --since argument which would doubtless > >> speed things up a lot, by truncating the history to, say, the last N > >> years. ?Also, it could possibly be rewritten to be faster still if it > >> started N simultaneous copies of git log simultaneously instead of in > >> sequence, and processed them incrementally rather than throwing them > >> into a giant hash table, which would also probably cut down memory > >> usage quite a bit. ?However, I'm not really inclined to spend a lot of > >> time on it unless it's actually bugging Tom. > > > > FWIW, I would find a --since option useful (since I use the equivalent > > option of cvs2cl), but those other refinements don't seem of interest. > > 14 seconds is already an order of magnitude or two faster than cvs2cl. > > I'm pretty sure that with such an option, you'd be down to sub-second speed. I assumed you would say git would produce the results before we asked for them. ;-) -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
Tom Lane wrote: > Robert Haas writes: > > It should get a bit faster if we reduce the number of branches it > > examines, which I assume is something we can do once we desupport 7.4 > > and 8.0. We could also add a --since argument which would doubtless > > speed things up a lot, by truncating the history to, say, the last N > > years. Also, it could possibly be rewritten to be faster still if it > > started N simultaneous copies of git log simultaneously instead of in > > sequence, and processed them incrementally rather than throwing them > > into a giant hash table, which would also probably cut down memory > > usage quite a bit. However, I'm not really inclined to spend a lot of > > time on it unless it's actually bugging Tom. > > FWIW, I would find a --since option useful (since I use the equivalent > option of cvs2cl), but those other refinements don't seem of interest. > 14 seconds is already an order of magnitude or two faster than cvs2cl. Yes, my operation on a year's worth of logs can take a few minutes. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
Robert Haas wrote: > On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote: > > On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote: > >> OK, try this. ?It takes about 14 seconds on my machine on my copy of > >> Magnus's test repository. ?Output looks like this: > > > > 14 seconds! ?That sound much too slow :-) > > /me is very sorry master. Please beat your unworthy servant only > lightly... or alternatively, buy me a faster machine. > > It should get a bit faster if we reduce the number of branches it > examines, which I assume is something we can do once we desupport 7.4 > and 8.0. We could also add a --since argument which would doubtless > speed things up a lot, by truncating the history to, say, the last N Yes, I will definately need a --since argument like cvs log -d which restricts by date. I usually find the data of the previous release and use that to pull cvs logs to create the release notes. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
On Tue, Aug 17, 2010 at 06:31, Stephen Frost wrote: > * Peter Eisentraut (pete...@gmx.net) wrote: >> Other comments? > > Will we be able to use it for psql while keeping just one database > connection? I assume the answer is 'no', but it sure would be nice.. I think thats something that could be worked out in libpq after this patch. Although I'd bump your nice to an awesome. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/pgSQL EXECUTE '..' USING with unknown
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes: > Here we are. A simple usecase. The reason you have an issue here is that the column is char(n) while the parameter is text. So the non-USING execute is equivalent to regression=# explain SELECT flag FROM foo where uid = 'cfcd208495d565ef66e7dff9f98764da'; QUERY PLAN Index Scan using foo_pkey on foo (cost=0.00..8.27 rows=1 width=1) Index Cond: (uid = 'cfcd208495d565ef66e7dff9f98764da'::bpchar) (2 rows) while the EXECUTE USING is equivalent to regression=# explain SELECT flag FROM foo where uid = 'cfcd208495d565ef66e7dff9f98764da'::text; QUERY PLAN Seq Scan on foo (cost=0.00..24.02 rows=5 width=1) Filter: ((uid)::text = 'cfcd208495d565ef66e7dff9f98764da'::text) (2 rows) and the reason you don't get an indexscan on the latter is that it's a TEXT comparison not a BPCHAR comparison; which is different because of the rules about ignoring trailing blanks. char(n) sucks. Avoid it if possible. If you insist on using it, be very very careful about which comparison semantics you're asking for. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
On tis, 2010-08-17 at 15:59 +0200, Erik Rijkers wrote: > creating template1 database in > /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1 ... > FATAL: could not > create unique index "pg_proc_oid_index" > DETAIL: Key (oid)=(2614) is duplicated. Probably merge conflict with parallel developments. Try changing the OID. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/pgSQL EXECUTE '..' USING with unknown
2010/8/17 Cédric Villemain : > 2010/8/17 Tom Lane : >> =?ISO-8859-1?Q?C=E9dric_Villemain?= >> writes: >>> 2010/8/16 Tom Lane : =?ISO-8859-1?Q?C=E9dric_Villemain?= writes: > Unfortunely the current implementation of EXECUTE USING is not working > this way. Uh ... what do you base that statement on? >> >>> About the planning behavior ? >>> With USING, I get a seqscan (cost and long), without USING I have an >>> indexscan(short and costless). >> >> It works as expected for me. What PG version are you using exactly? >> Could you provide a self-contained example? > > postgresql 8.4.4. Yes I'll work one out this evening. > more or less : table foo (uid char(32) PK, flag boolean), uids are > md5sum. +-6M rows. Here we are. A simple usecase. -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support usecase_exec_using.sql Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
On tis, 2010-08-17 at 08:31 -0400, Stephen Frost wrote: > Will we be able to use it for psql while keeping just one database > connection? I assume the answer is 'no', but it sure would be nice.. How do you expect that to behave? I suppose the backend could send NOTICE-like messages every 1% or so, and then psql could try to display that in some way (which?), but then I suspect that a) it will annoy some people, so b) it will have to be off by default, and then c) it won't be enabled when you need it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] security label support, part.2
>Stephen Frost wrote: > Let's not build the complication of dealing with inheiritance/ > child relations into the external security system when we're in > the middle of trying to get rid of that distinction in core PG > though. I didn't realize we were trying to do that. I know we're working on making partitioning easier, but there hasn't been a decision to stop supporting other uses of inheritance, has there? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/pgSQL EXECUTE '..' USING with unknown
2010/8/17 Tom Lane : > =?ISO-8859-1?Q?C=E9dric_Villemain?= > writes: >> 2010/8/16 Tom Lane : >>> =?ISO-8859-1?Q?C=E9dric_Villemain?= >>> writes: Unfortunely the current implementation of EXECUTE USING is not working this way. >>> >>> Uh ... what do you base that statement on? > >> About the planning behavior ? >> With USING, I get a seqscan (cost and long), without USING I have an >> indexscan(short and costless). > > It works as expected for me. What PG version are you using exactly? > Could you provide a self-contained example? postgresql 8.4.4. Yes I'll work one out this evening. more or less : table foo (uid char(32) PK, flag boolean), uids are md5sum. +-6M rows. -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
>> On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
>>> /me is very sorry master. Please beat your unworthy servant only
>>> lightly... or alternatively, buy me a faster machine.
>>
>> Well, I might be able to afford a beer.
>
> Done!
Well on 2nd thought, maybe not... If people start collecting I'll be
broke (notably I owe tom quite a few :-).
Anyway find below version that passes any arguments through to git-log.
Now you can do git-topo-order --since='1 year', takes a whopping
0.430s for me :-)
--
--- git-topo-order (1) 2010-08-17 09:44:18.069517261 -0600
+++ git-topo-order 2010-08-17 09:45:34.109812004 -0600
@@ -26,6 +26,7 @@
use strict;
use warnings;
require Date::Calc;
+use IPC::Open2;
my @BRANCHES = qw(master REL9_0_STABLE REL8_4_STABLE REL8_3_STABLE
REL8_2_STABLE REL8_1_STABLE REL8_0_STABLE REL7_4_STABLE);
@@ -34,11 +35,13 @@
my %all_commits_by_branch;
my %commit;
+my %position;
for my $branch (@BRANCHES) {
my $commitnum = 0;
- open(GITLOG, "git log --date=iso origin/$branch |")
+ $position{$branch} = 0;
+ open2(my $git_out, my $git_in, qw(git log --date=iso), @ARGV,
"origin/$branch")
|| die "can't run git log origin/$branch: $!";
- while (my $line = ) {
+ while (my $line = <$git_out>) {
if ($line =~ /^commit\s+(.*)/) {
push_commit(\%commit) if %commit;
%commit = (
@@ -60,10 +63,6 @@
}
}
-my %position;
-for my $branch (@BRANCHES) {
- $position{$branch} = 0;
-}
while (1) {
my $best_branch;
my $best_inversions;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] outPlannedStmt missing transientPlan
Yeb Havinga writes: > This message is probably in the top 10 of 2010's most insignificant > messages, but: > _outPlannedStmt does not write the bool field transientPlan and it is > not accompanied by the comment /* NB: this isn't a complete set of > fields */ that exist at other places. [ squint... ] That's weird. copyfuncs.c is missing the field too, which might be a less insignificant bug. Will fix once we have a working SCM again. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] refactoring comment.c
I wrote: > Maybe so, but the parser is expected to put out a representation that > will still be valid when the command is executed some time later. Rereading this, I see I didn't make my point very clearly. The reason this code doesn't belong in parser/ is that there's no prospect the parser itself would ever use it. ObjectAddress is an execution-time creature because we don't want utility statement representations to be resolved to OID-level detail before they execute. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote: > On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote: >> /me is very sorry master. Please beat your unworthy servant only >> lightly... or alternatively, buy me a faster machine. > > Well, I might be able to afford a beer. Done! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote: > On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote: >> On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote: >>> OK, try this. It takes about 14 seconds on my machine on my copy of >>> Magnus's test repository. Output looks like this: >> >> 14 seconds! That sound much too slow :-) > > /me is very sorry master. Please beat your unworthy servant only > lightly... or alternatively, buy me a faster machine. Well, I might be able to afford a beer. I do think 14 seconds is quite amazing. > It should get a bit faster if we reduce the number of branches it > examines, which I assume is something we can do once we desupport 7.4 > and 8.0. We could also add a --since argument which would doubtless > speed things up a lot, by truncating the history to, say, the last N > years. Presumably that could even be from the last point release to HEAD. > Despite the fact that I wrote this basically in response to Tom's > complaint, I do think that it's generally useful, and will likely use > it myself from time to time. Yeah, I might find it useful as well which is why I chimed in. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane wrote: > Robert Haas writes: >> It should get a bit faster if we reduce the number of branches it >> examines, which I assume is something we can do once we desupport 7.4 >> and 8.0. We could also add a --since argument which would doubtless >> speed things up a lot, by truncating the history to, say, the last N >> years. Also, it could possibly be rewritten to be faster still if it >> started N simultaneous copies of git log simultaneously instead of in >> sequence, and processed them incrementally rather than throwing them >> into a giant hash table, which would also probably cut down memory >> usage quite a bit. However, I'm not really inclined to spend a lot of >> time on it unless it's actually bugging Tom. > > FWIW, I would find a --since option useful (since I use the equivalent > option of cvs2cl), but those other refinements don't seem of interest. > 14 seconds is already an order of magnitude or two faster than cvs2cl. I'm pretty sure that with such an option, you'd be down to sub-second speed. >> So I think we should consider checking it into src/tools. > > +1 ... but not today ;-) :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
Robert Haas writes: > It should get a bit faster if we reduce the number of branches it > examines, which I assume is something we can do once we desupport 7.4 > and 8.0. We could also add a --since argument which would doubtless > speed things up a lot, by truncating the history to, say, the last N > years. Also, it could possibly be rewritten to be faster still if it > started N simultaneous copies of git log simultaneously instead of in > sequence, and processed them incrementally rather than throwing them > into a giant hash table, which would also probably cut down memory > usage quite a bit. However, I'm not really inclined to spend a lot of > time on it unless it's actually bugging Tom. FWIW, I would find a --since option useful (since I use the equivalent option of cvs2cl), but those other refinements don't seem of interest. 14 seconds is already an order of magnitude or two faster than cvs2cl. > So I think we should consider checking it into src/tools. +1 ... but not today ;-) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/pgSQL EXECUTE '..' USING with unknown
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes: > 2010/8/16 Tom Lane : >> =?ISO-8859-1?Q?C=E9dric_Villemain?= >> writes: >>> Unfortunely the current implementation of EXECUTE USING is not working >>> this way. >> >> Uh ... what do you base that statement on? > About the planning behavior ? > With USING, I get a seqscan (cost and long), without USING I have an > indexscan(short and costless). It works as expected for me. What PG version are you using exactly? Could you provide a self-contained example? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
On Tue, Aug 17, 2010 at 4:17 PM, Robert Haas wrote: > On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote: >> On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote: >>> OK, try this. It takes about 14 seconds on my machine on my copy of >>> Magnus's test repository. Output looks like this: >> >> 14 seconds! That sound much too slow :-) > > /me is very sorry master. Please beat your unworthy servant only > lightly... or alternatively, buy me a faster machine. > > It should get a bit faster if we reduce the number of branches it > examines, which I assume is something we can do once we desupport 7.4 > and 8.0. We could also add a --since argument which would doubtless > speed things up a lot, by truncating the history to, say, the last N > years. Also, it could possibly be rewritten to be faster still if it > started N simultaneous copies of git log simultaneously instead of in > sequence, and processed them incrementally rather than throwing them > into a giant hash table, which would also probably cut down memory > usage quite a bit. However, I'm not really inclined to spend a lot of > time on it unless it's actually bugging Tom. > > Despite the fact that I wrote this basically in response to Tom's > complaint, I do think that it's generally useful, and will likely use > it myself from time to time. So I think we should consider checking > it into src/tools. Perhaps someone will feel an urge to hack on it > further. Another useful enhancement would be to allow it to run on +1 for putting this in src/tools. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fw: patch for pg_ctl.c to add windows service start-type
On Tue, Aug 17, 2010 at 2:58 PM, Quan Zongliang wrote: > > Sorry. > I forget to attach the patch file. Without looking at the details of this patch, it looks reasonable - so please put it on the commitfest page, if you haven't already. It does, however, lack documentation updates - that needs to be done before it can get applied. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote: > On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote: >> OK, try this. It takes about 14 seconds on my machine on my copy of >> Magnus's test repository. Output looks like this: > > 14 seconds! That sound much too slow :-) /me is very sorry master. Please beat your unworthy servant only lightly... or alternatively, buy me a faster machine. It should get a bit faster if we reduce the number of branches it examines, which I assume is something we can do once we desupport 7.4 and 8.0. We could also add a --since argument which would doubtless speed things up a lot, by truncating the history to, say, the last N years. Also, it could possibly be rewritten to be faster still if it started N simultaneous copies of git log simultaneously instead of in sequence, and processed them incrementally rather than throwing them into a giant hash table, which would also probably cut down memory usage quite a bit. However, I'm not really inclined to spend a lot of time on it unless it's actually bugging Tom. Despite the fact that I wrote this basically in response to Tom's complaint, I do think that it's generally useful, and will likely use it myself from time to time. So I think we should consider checking it into src/tools. Perhaps someone will feel an urge to hack on it further. Another useful enhancement would be to allow it to run on just those commits whose log message includes a certain string. This would be useful for answering the question "which branches was this patch committed to?". Of course, you can find that out using the existing implementation also by searching the output, but this would be more convenient (and faster). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Attention committers: no more CVS commits, please!
Bruce Momjian writes: > Tom Lane wrote: >> IOW, please no more CVS commits after 14:00 GMT tomorrow, Tuesday 8/17. > OK, would someone please send an email to hackers at that time as a > reminder? I might not be available then. Here you go. Per yesterday's discussion, access to the master PG CVS repository will be shut off at approximately 17:00 GMT, three hours from now, to begin the conversion to git. So that all interested people can capture final snapshots of the repository for archival purposes, please do not make any further commits into the CVS repository. Development will resume once the git repository is up and validated. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CVS to GIT conversion - repository freeze
Hello! Here's a reminder, as requested: As of now (14:00 GMT), the cvs repository is frozen. This means that no new commits may be made to the cvs repository anymore! It is still possible to do a cvs update or log or such operations, but please - no more commits until we have the git stuff up and running! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
On Tue, August 17, 2010 07:19, Peter Eisentraut wrote: > Here is a small prototype for a query progress indicator. > The patch applies to cvs HEAD (9.1devel) and compiles OK, but make check fails. ./configure --prefix=/var/data1/pg_stuff/pg_installations/pgsql.progress_indicator --with-pgport=6548 --quiet --enable-depend --enable-cassert --enable-debug --with-openssl --with-perl --with-libxml Running initdb manually gives the following error: $ /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/bin/initdb -U rijkers -D /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data -E UTF8 -A md5 --pwfile=/var/data1/pg_stuff/.90devel The files belonging to this database system will be owned by user "rijkers". This user must also own the server process. The database cluster will be initialized with locale en_US.UTF-8. The default text search configuration will be set to "english". creating directory /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1 ... FATAL: could not create unique index "pg_proc_oid_index" DETAIL: Key (oid)=(2614) is duplicated. child process exited with exit code 1 initdb: removing data directory "/var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data" this is on centos 5.4 - x86_64 GNU/Linux (2.6.18-164.el5) Erik Rijkers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Todays git migration results
On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote: > OK, try this. It takes about 14 seconds on my machine on my copy of > Magnus's test repository. Output looks like this: 14 seconds! That sound much too slow :-) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Fw: patch for pg_ctl.c to add windows service start-type
Sorry. I forget to attach the patch file. Begin forwarded message: Date: Mon, 16 Aug 2010 19:49:20 +0800 From: Quan Zongliang To: pgsql-hackers@postgresql.org Subject: patch for pg_ctl.c to add windows service start-type Hi, all I modified pg_ctl.c to add a new option for Windows service start-type. new option is -S [auto|demand] For example, the command can be used under Windows: pg_ctl register -N "s-name" -S auto or pg_ctl register -N "s-name" -S demand The created service will be SERVICE_AUTO_START or SERVICE_DEMAND_START respectively. regards -- Quan Zongliang -- Quan Zongliang pg_ctl.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Progress indication prototype
* Peter Eisentraut (pete...@gmx.net) wrote: > Other comments? Will we be able to use it for psql while keeping just one database connection? I assume the answer is 'no', but it sure would be nice.. Perhaps psql could do something for \copy commands, anyway, but it'd be independent. Thanks, Stephen signature.asc Description: Digital signature
[HACKERS] outPlannedStmt missing transientPlan
This message is probably in the top 10 of 2010's most insignificant messages, but: _outPlannedStmt does not write the bool field transientPlan and it is not accompanied by the comment /* NB: this isn't a complete set of fields */ that exist at other places. regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git migration timeline
On Tue, Aug 17, 2010 at 11:50:20AM +0200, Magnus Hagander wrote: > What about 9.0? Will come in a few minutes. I didn't have a checked out version of the 9.0 branch handy in my development environment. Regression test is currently running. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/pgSQL EXECUTE '..' USING with unknown
2010/8/16 Tom Lane : > =?ISO-8859-1?Q?C=E9dric_Villemain?= > writes: >> Yes, and you point out another thing. EXECUTE is a way to bypass the >> named prepare statement, to be sure query is replanned each time. >> Unfortunely the current implementation of EXECUTE USING is not working >> this way. > > Uh ... what do you base that statement on? About the planning behavior ? With USING, I get a seqscan (cost and long), without USING I have an indexscan(short and costless). And the pg_stat* views confirm that the index is not used. I think that the relevant code is in exec_dynquery_with_params(...). The SPI_cursor_open_with_args receive a complete string, or a string + params. My use case is very simple: EXECUTE 'SELECT status FROM ' || l_partname::regclass || ' WHERE uid = ' || quote_literal(p_uid) INTO r.flag; vs EXECUTE 'SELECT status FROM ' || l_partname::regclass || ' WHERE uid = $1' USING p_uid INTO r.flag; (here it is not bad, but I was very happy to be able to do a safe uid = ANY ($1), with p_uid an array in another context.) > > regards, tom lane > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git migration timeline
On Tue, Aug 17, 2010 at 11:46 AM, Michael Meskes wrote: > On Mon, Aug 16, 2010 at 02:50:35PM -0400, Tom Lane wrote: >> Better a memory leak than broken ecpg ;-). Nobody except Michael >> is terribly comfortable with that code, so we'd all rather wait for >> him to review and apply the patch. > > This patch was small enough that I felt good about it without having a > chance > to test it. Anyway, I applied Zoltan's memleak patch to HEAD and 8.4. What about 9.0? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git migration timeline
On Mon, Aug 16, 2010 at 02:50:35PM -0400, Tom Lane wrote: > Better a memory leak than broken ecpg ;-). Nobody except Michael > is terribly comfortable with that code, so we'd all rather wait for > him to review and apply the patch. This patch was small enough that I felt good about it without having a chance to test it. Anyway, I applied Zoltan's memleak patch to HEAD and 8.4. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Git migration timeline
On Tue, Aug 17, 2010 at 1:59 AM, Tom Lane wrote: > Magnus Hagander writes: >> According to the decision at the developer meeting, the migration to >> git should happen 17-20 Aug. Here's my proposed timeline. This will >> obviously affect development work some, and since the original >> timeline called for us having already released 9.0 buy then ;) > >> 1. Tuesday evening, around 19:00 central european time, which is 17:00 >> GMT or 12:00 EST, I will freeze the current cvs repository. I will do >> this by disabling committer login on that box, so please note that >> this will also make it impossible for committers to do a "cvs update" >> from the authenticated repository. > > So, per discussion, I'd like to suggest that we have a "quiet time" for > say three hours before the repository is closed off, to give interested > committers a chance to capture final snapshots of the current > repository. > > IOW, please no more CVS commits after 14:00 GMT tomorrow, Tuesday 8/17. Works for me. I'll send out status reports as I change things, so be sure to check the latest on -hackers if something you thought would work doesn't ;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Writeable CTEs Desgin Doc on Wiki
On 2010-08-17 6:41 AM +0300, Hitoshi Harada wrote: 2010/8/17 Robert Haas: There are really two separate features here, and it might be worth giving them separate names and separate designs (and separate patches). Allowing the main query to be an insert, update, or delete seems easier than allowing the toplevel CTEs to contain those constructs, although I might be wrong about that. Under features, what is DCL? There has been previous talk of allowing WITH (COPY ...) and I am personally of the opinion that it would be nice to be able to do WITH (EXPLAIN ...). DDL seems like a poor idea. So, there are three? One for allowing the main query to be an insert, update, or delete, one for the main subject of writeable CTE with insert, update, delete and one for allowing COPY to return rows. I am attracted by such COPY functionality. And the first part seems easier to be committed separately. Is it possible to get it in by only adding syntax and little parser/planner modification, or more executor code? It's not that simple, see: http://archives.postgresql.org/pgsql-hackers/2010-02/msg01065.php Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
