Tom Lane wrote:
It shouldn't be a big problem, assuming the checkout preserves the file
dates --- they'll look older than the source files and so a rebuild will
happen anyway in such a checkout.
Actually this is a problem with at least SVN. A "svn export" will
create files with the original
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> Now, on my hand-crafted GIT repo - you see them in and out now with
> Tom's commits. But any *real* conversion tracking the *actual* RCS cvs
> states should have them checked out from 1999 to now in the state they
> were from vadim's last changes, and To
* Tom Lane <[EMAIL PROTECTED]> [070416 21:11]:
> I wrote:
> > So there's no way, apparently, to fix the state of these files through
> > the "front door".
>
> I take that back: the right sequence involving a "cvs update" got me
> into a state where it thought the files were "locally modified", and
Andrew Dunstan wrote:
> Tom Lane wrote:
> >So there's no way, apparently, to fix the state of these files through
> >the "front door". Shall we try the proposed idea of hand-moving the
> >files out of the Attic subdirectory, whereupon they should appear live
> >and we can cvs remove them again?
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
What's more, we have a SoC project for column level access controls.
... which presumably wouldn't involve any added dependency on outside code.
Quite so. You can see the project description at
http://code.google.com/so
Tom Lane wrote:
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
* Tom Lane <[EMAIL PROTECTED]> [070416 19:03]:
I like the idea of re-adding and then re-removing the files on HEAD.
Does anyone think that poses any real risk?
No - it even fixed the "hand moved" test I had done tryi
I wrote:
> So there's no way, apparently, to fix the state of these files through
> the "front door".
I take that back: the right sequence involving a "cvs update" got me
into a state where it thought the files were "locally modified", and
then I could commit and "cvs remove" and commit again. So
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> * Tom Lane <[EMAIL PROTECTED]> [070416 19:03]:
>> I like the idea of re-adding and then re-removing the files on HEAD.
>> Does anyone think that poses any real risk?
> No - it even fixed the "hand moved" test I had done trying to create an
> Attic with,
Florian Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> The current documentation for RESET exhibits a certain lack of, um,
>>> intellectual cohesiveness:
> What about
> RESET parameter
> RESET { PLANS | TEMP | TEMPORARY }
> RESET ALL { PARAMETERS | STATE }
> RESET ALL would become an abb
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The current documentation for RESET exhibits a certain lack of, um,
intellectual cohesiveness:
Synopsis
RESET configuration_parameter
RESET ALL
RESET { PLANS | SESSION | TEMP | TEMPORARY }
Maybe DISCARD for the plans
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> What's more, we have a SoC project for column level access controls.
... which presumably wouldn't involve any added dependency on outside code.
For people who are already using SELinux or Trusted Solaris, making the
database dependent on that infrast
Josh Berkus <[EMAIL PROTECTED]> writes:
> Column level? We don't currently support that, except through VIEWs.
> How is it implemented?
It wasn't clear to me how much of this is actually working today and how
much is a paper design --- one thing in particular that stood out as
probable handwaving
* Tom Lane <[EMAIL PROTECTED]> [070416 19:03]:
> Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> > Would anyone know if these were "hand moved" to Attic?
>
> Seems unlikely, since there's a commit log entry for the removal. But
> this all happened seven-plus years ago and I'm sure there's an old CVS
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The current documentation for RESET exhibits a certain lack of, um,
>> intellectual cohesiveness:
>>
>> Synopsis
>>
>> RESET configuration_parameter
>> RESET ALL
>> RESET { PLANS | SESSION | TEMP | TEMPORARY }
> Maybe DISCARD for the
Josh Berkus wrote:
> KaiGai,
>
>> It provides database users fine grained mandatory access control
>> including row and column level one, and integration with operating
>> system security policy.
>
> Column level? We don't currently support that, except through VIEWs.
> How is it implemented?
>
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> Would anyone know if these were "hand moved" to Attic?
Seems unlikely, since there's a commit log entry for the removal. But
this all happened seven-plus years ago and I'm sure there's an old CVS
bug involved *somewhere*.
I like the idea of re-adding a
KaiGai,
> It provides database users fine grained mandatory access control
> including row and column level one, and integration with operating
> system security policy.
Column level? We don't currently support that, except through VIEWs.
How is it implemented?
--Josh
-
* Florian G. Pflug <[EMAIL PROTECTED]> [070416 16:16]:
> >I think this is a corner case that CVS handles in a particular way and
> >the tools people are using to read the repository handle in a different
> >way. Which would be a bug in those tools, since CVS's interpretation
> >must be right by d
[EMAIL PROTECTED] (Aidan Van Dyk) writes:
> I've "diffed" a CVS checkout and a git checkout, and the are *almost*
> identical. Almost, because it seems like my git repository currently has 3
> files that a cvs checkout doesn't:
> backend/parser/gram.c |12088 ++
[EMAIL PROTECTED] ("Florian G. Pflug") writes:
> Martin Langhoff wrote:
>> Hi Florian,
>> I am right now running an rsync of the Pg CVS repo to my work
>> machine to
>> get a git import underway. I'm rather keen on seeing your cool PITR Pg
>> project go well and I have some git+cvs fu I can apply h
On Mon, 2007-04-16 at 03:48 +0200, Florian G. Pflug wrote:
> I just realized that this file isn't even in the postgresql CVS
> repo. But it _is_ part of the SVN mirror at
> https://projects.commandprompt.com/public/pgsql/repo.
[...]
> Seems to be a bug in the CVS->SVN conversion process...
The roo
Andrew Dunstan írta:
Florian G. Pflug wrote:
bison -y -d gram.y
conflicts: 2 shift/reduce
I'ts been quite a time since I last used bison, but as far as I
remember, you can tell it to write a rather details log about
it's analysis of the grammar. That log should include more
detailed informat
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
These files are generated (from gram.y, pgc.l and preproc.y
respectievly) and are not present in the CVS repo, though I think they
have been at some point.
It's strange that other generated files (that have also been in the repo
in th
"Jacky Leng" <[EMAIL PROTECTED]> writes:
> Shouldn't we write xlog record before we do a physical operation?
The reasoning for not doing it that way was that we can't be sure
beforehand that the filesystem operation will succeed. If we xlog
the truncate first, it fails, and then we crash, we're i
Heikki Linnakangas wrote:
That's a clever trick, but I can't help thinking we really should have
an explicit field in the page header to indicate what kind of a page it
is. It would make life simpler for any external tools that want to peek
into pages, including migration utilities after a r
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> These files are generated (from gram.y, pgc.l and preproc.y
> respectievly) and are not present in the CVS repo, though I think they
> have been at some point.
> It's strange that other generated files (that have also been in the repo
> in the past) lik
Florian G. Pflug wrote:
bison -y -d gram.y
conflicts: 2 shift/reduce
I'ts been quite a time since I last used bison, but as far as I
remember, you can tell it to write a rather details log about
it's analysis of the grammar. That log should include more
detailed information about those confli
Hiroshi Saito wrote:
> Hi.
>
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
>
>> I see.
>>
>> But - does it work when build with MSVC6? IIRC, MSVC6 pre-dates windows
>> 2000 and the windows IPV6 support.
>>
>> Can you verify that it works if you manually add this #define and build
>> with MSVC6?
>
Zoltan Boszormenyi wrote:
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
Also, the current grammar is made to give a syntax error
if you say "colname type GENERATED BY DEFAULT AS ( expr )".
But it makes the grammar unbalanced, and gives me:
bison -y -d gram.y
conflicts: 2 shift/
Aidan Van Dyk wrote:
> I've "diffed" a CVS checkout and a git checkout, and the are *almost*
> identical. Almost, because it seems like my git repository currently has 3
> files that a cvs checkout doesn't:
> backend/parser/gram.c |12088 +++
> interfaces/ecpg
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> "GENERATED BY DEFAULT AS ( expr )" is another
> way of saying "DEFAULT expr" but that being similar
> to GENERATED ALWAYS AS ( expr ) would make
> the users think that it would permit smarter expressions
> than simple DEFAULT would allow. My thought
Aidan Van Dyk wrote:
Martin Langhoff wrote:
Well, now that more than one of us are working with git on PostgreSQL...
I've had a repo conversion running for a while... I've only got it to what
I consider "stable" last week:
http://repo.or.cz/w/PostgreSQL.git
git://repo.or.cz/PostgreSQL.g
Martin Langhoff wrote:
Hi Florian,
I am right now running an rsync of the Pg CVS repo to my work machine to
get a git import underway. I'm rather keen on seeing your cool PITR Pg
project go well and I have some git+cvs fu I can apply here (being one
of the git-cvsimport maintainers) ;-)
Cool -
* Aidan Van Dyk <[EMAIL PROTECTED]> [070416 14:08]:
> Note that this is a "special" conversion - I intentionally "unmunge" all the
> $PostgreSQL$ tags in this repo.
Blah - and I just noticed that I actually "missed" the $PostgreSQL$
(although I did catch the Date/Modified/From/etc)...
> I hat
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
Apart from making the patch a bit smaller again, checking only
for 'i' still allows multiple SERIALs in the same table but lets
disallowing multiple GENERATED ALWAYS AS IDENTITY.
Thinking a bit about it, is it desired to disallow m
Martin Langhoff wrote:
> Hi Florian,
>
> I am right now running an rsync of the Pg CVS repo to my work machine to
> get a git import underway. I'm rather keen on seeing your cool PITR Pg
> project go well and I have some git+cvs fu I can apply here (being one
> of the git-cvsimport maintainers) ;
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Apart from making the patch a bit smaller again, checking only
> for 'i' still allows multiple SERIALs in the same table but lets
> disallowing multiple GENERATED ALWAYS AS IDENTITY.
> Thinking a bit about it, is it desired to disallow multiple GENER
Hi Florian,
I am right now running an rsync of the Pg CVS repo to my work machine to
get a git import underway. I'm rather keen on seeing your cool PITR Pg
project go well and I have some git+cvs fu I can apply here (being one
of the git-cvsimport maintainers) ;-)
For the kind of work you'll be d
Shouldn't we write xlog record before we do a physical operation?
An test case:
1. set full_page_writes off;
2. startup database; create a table; insert 10 rows in it; shutdown
database;
3. startup database again; delete all rows from this table;
4. vacuum this table, and it will come into smg
Hi,
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
So, I should allow DROP DEFAULT, implement
SET DEFAULT GENERATED ALWAYS AS
and modify the catalog so the GENERATED property
is part of pg_attrdef.
Sounds good.
Fin
Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
If we expose LET_OS_MANAGE_FILESIZE, should we add a flag to the
control file so that you can't start a backend that has that defined
against a cluster that was initialized without it?
I imagine we'd flag that as relsegsize = 0 or some s
Joshua D. Drake wrote:
http://projects.commandprompt.com/public/pgsql/browser
or do the anonymous checkout with:
svn co http://projects.commandprompt.com/public/pgsql/repo/
But if you have a checked out tree, does it work to do an update after
the tree has been regenerated? As far as I know,
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Alvaro Herrera wrote:
Ah, it seems the SVN repo just got its first user ;-) Congratulations.
Ask Joshua to send you a Command Prompt tee shirt, maybe he is excited
enough.
I hope the fact that I use the SVN repo just to get the changes into
git do
As I announced alpha version of SE-PostgreSQL about one month ago,
I'm working for development of a security facility integrated with
secure operating system.
It provides database users fine grained mandatory access control
including row and column level one, and integration with operating
system
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I guess the issue is that I'd expect public to be owned by the DB Owner after
> a CREATE DATABASE foo OWNER bar,
Why? Do you expect the system catalogs to be owned by the DB owner?
What about other random objects that might have been created in the
tem
http://projects.commandprompt.com/public/pgsql/browser
or do the anonymous checkout with:
svn co http://projects.commandprompt.com/public/pgsql/repo/
But if you have a checked out tree, does it work to do an update after
the tree has been regenerated? As far as I know, the repo is generated
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> That is, why can't you write
> SELECT 1 IN ( ARRAY[1, 2, 3] );
> when you can write
> SELECT 1 = ANY ( ARRAY[1, 2, 3] );
> ?
The two syntaxes are in fact *not* equivalent according to SQL92.
= ANY derives from
::=
On Mon, 16 Apr 2007, Tom Lane wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
When I try and RESTORE a pg_dump in the current state, we get errors because
the public schema is owned by postgres, and the grant commands are issued
as the user (since I'm restoring as the purported owner.
That'
Florian G. Pflug wrote:
> Alvaro Herrera wrote:
> >Ah, it seems the SVN repo just got its first user ;-) Congratulations.
> >Ask Joshua to send you a Command Prompt tee shirt, maybe he is excited
> >enough.
>
> I hope the fact that I use the SVN repo just to get the changes into
> git doesn't red
Larry Rosenman <[EMAIL PROTECTED]> writes:
> When I try and RESTORE a pg_dump in the current state, we get errors because
> the public schema is owned by postgres, and the grant commands are issued
> as the user (since I'm restoring as the purported owner.
That's a different issue entirely, which
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
> Shouldn't everything that is in the DB be owned by the purported owner?
Not any more than the owner of a schema owns everything in it.
regards, tom lane
---(end of broadcast)---
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> That's a clever trick, but I can't help thinking we really should have
> an explicit field in the page header to indicate what kind of a page it
> is.
I think we should save the pd_flags field for cases where we really need
it ...
Andrew Dunstan wrote:
> Alvaro Herrera wrote:
> >Larry Rosenman wrote:
> >
> >>Greetings,
> >>I think I found a bug, or at least a POLA violation. At work, I
> >>created
> >>a user that is NOT a superuser, nor can that user create databases. When
> >>I
> >>did a create database foo ow
Alvaro Herrera wrote:
Ah, it seems the SVN repo just got its first user ;-) Congratulations.
Ask Joshua to send you a Command Prompt tee shirt, maybe he is excited
enough.
I hope the fact that I use the SVN repo just to get the changes into
git doesn't reduce my chances of getting that t-shirt
Alvaro Herrera wrote:
Larry Rosenman wrote:
Greetings,
I think I found a bug, or at least a POLA violation. At work, I created
a user that is NOT a superuser, nor can that user create databases. When I
did a create database foo owner bar, all the schemas are set to be owned by
the super
Larry Rosenman wrote:
> Greetings,
> I think I found a bug, or at least a POLA violation. At work, I created
> a user that is NOT a superuser, nor can that user create databases. When I
> did a create database foo owner bar, all the schemas are set to be owned by
> the superuser that created
On Mon, 16 Apr 2007, Andrew Dunstan wrote:
Larry Rosenman wrote:
Greetings,
I think I found a bug, or at least a POLA violation. At work, I
created
a user that is NOT a superuser, nor can that user create databases. When I
did a create database foo owner bar, all the schemas are set to
Larry Rosenman wrote:
Greetings,
I think I found a bug, or at least a POLA violation. At work, I created
a user that is NOT a superuser, nor can that user create databases. When I
did a create database foo owner bar, all the schemas are set to be owned by
the superuser that created the data
Florian G. Pflug wrote:
> Tom Lane wrote:
> >"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> >>When I try to build CVS HEAD on OSX 10.4, compiling
> >>src/interfaces/ecpg/preproc/preproc.c fails with:
> >>...
> >>If I delete pgc.c, it is rebuilt automatically, and then
> >>preproc.c compiles just
Greetings,
I think I found a bug, or at least a POLA violation. At work, I created
a user that is NOT a superuser, nor can that user create databases. When I
did a create database foo owner bar, all the schemas are set to be owned by
the superuser that created the database, not the database o
Hi,
Could you Bruce please add a TODO item for this feature?
The description could look something like this:
Eliminate the table T from the query/subquery if the following requirements
are satisfied:
1. T is left joined
2. T is referenced only in the join expression where it is left joined
3. th
Tom Lane wrote:
Gavin Sherry <[EMAIL PROTECTED]> writes:
On Mon, 9 Apr 2007, Tom Lane wrote:
... I don't see any way to make it completely bulletproof
without enlarging the special space, which seems an unreasonable price
to pay. But even one chance in 16K is way better than the current
situat
62 matches
Mail list logo
