[HACKERS] IN with arrays
I'm wondering why a IN b isn't equivalent to a = ANY b for arrays, as it is for subqueries. 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] ); ? I'm guessing that there is a semantic inconsistency between these expressions, as the first one considers what is in parentheses as a list, the second one as a single expression. That would be very bad. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Adjusting index special storage for pg_filedump's convenience
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 situation. Sounds like the only workable approach. Actually, I realized after writing that that it *is* possible to make it bulletproof: all we have to do is make the BTCycleId wrap around at a little less than 64K, which adds about one line of code and doesn't materially change its reliability. That leaves a few bitpatterns free for IDs of other index types with no chance of collision. I made hash use 0xFF80 and gist 0xFF81; please use 0xFF82 for bitmaps. (GIN turns out not to need a code because its special space is a different size, so we can tell it apart anyway.) See patch already committed here: http://archives.postgresql.org/pgsql-committers/2007-04/msg00125.php 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 release or two. We've also been talking about setting hint bits and doing some kind of retail vacuuming in bgwriter with HOT. To do that, we need to identify heap pages in the bgwriter. While heap pages can currently be identified by the fact that they don't have a special area, it feels hackish, and we might want to do something like that for index pages too in the future. We now have a 16-bit pd_flags field in the page header. We could use a few bits from that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Eliminating unnecessary left joins
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. the left join's join expression is a simple equality expression like T1.C1=T2.C2; T1!=T2 and (T==T1 or T==T2) 4. the column of T in the join exression is the primary key of T I hope it is comlete. I think this is the simplest case, so we should start with this. Thanks, Otto
[HACKERS] CREATE DATABASE foo OWNER bar
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 owner. Shouldn't everything that is in the DB be owned by the purported owner? This is on 8.2.3, btw. Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] CREATE DATABASE foo OWNER bar
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 database, not the database owner. Shouldn't everything that is in the DB be owned by the purported owner? This is on 8.2.3, btw. Thanks! umm ... objects are initially owned by their creator, no? Ownership of a db means you can grant privs over the db, but ownership doesn't cascade. If you want your user to own objects you should arrange for that user to create them, or run ALTER objtype foo OWNER TO username. The latter is what pg_dump does. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] CREATE DATABASE foo OWNER bar
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 be owned by the superuser that created the database, not the database owner. Shouldn't everything that is in the DB be owned by the purported owner? This is on 8.2.3, btw. Thanks! umm ... objects are initially owned by their creator, no? Ownership of a db means you can grant privs over the db, but ownership doesn't cascade. If you want your user to own objects you should arrange for that user to create them, or run ALTER objtype foo OWNER TO username. The latter is what pg_dump does. the issue is the initial schemas like PUBLIC. 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. It would seem to me, that the CREATE DATABASE command should change the owner of them to the OWNER verb. $ psql postgres Welcome to psql 8.2.3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# \du test List of roles Role name | Superuser | Create role | Create DB | Connections | Member of ---+---+-+---+-+--- test | no| no | no| no limit| (1 row) postgres=# create database testing owner test; CREATE DATABASE postgres=# \c test You are now connected to database test. test=# \dn List of schemas Name| Owner +--- information_schema | pgsql pg_catalog | pgsql pg_toast | pgsql public | pgsql (4 rows) test=# I would have expected these to be owned by test... cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] CREATE DATABASE foo OWNER bar
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 database, not the database owner. Shouldn't everything that is in the DB be owned by the purported owner? Right. This is on TODO: %Set proper permissions on non-system schemas during db creation Currently all schemas are owned by the super-user because they are copied from the template1 database. I note it is marked with a %, but it's clearly not easy at all. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] CREATE DATABASE foo OWNER bar
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 superuser that created the database, not the database owner. Shouldn't everything that is in the DB be owned by the purported owner? Right. This is on TODO: %Set proper permissions on non-system schemas during db creation Currently all schemas are owned by the super-user because they are copied from the template1 database. I note it is marked with a %, but it's clearly not easy at all. If it's only schemas I don't see why it would be very hard. If you want that to cascade to all non-system objects, as Larry suggests, it would possibly be harder. In the most common case it will only be the public schema and that will be empty. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Build-Problem with pgc.c on OSX 10.4
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 ;-) greetings, Florian Pflug ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] CREATE DATABASE foo OWNER bar
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 owner bar, all the schemas are set to be owned by the superuser that created the database, not the database owner. Shouldn't everything that is in the DB be owned by the purported owner? Right. This is on TODO: %Set proper permissions on non-system schemas during db creation Currently all schemas are owned by the super-user because they are copied from the template1 database. I note it is marked with a %, but it's clearly not easy at all. If it's only schemas I don't see why it would be very hard. If you want that to cascade to all non-system objects, as Larry suggests, it would possibly be harder. In the most common case it will only be the public schema and that will be empty. There was already a patch (by Fabien Coelho IIRC) but it was never applied. ... searches for a while ... Ah, yes, here it is: http://archives.postgresql.org/pgsql-patches/2004-06/msg00084.php -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Adjusting index special storage for pg_filedump's convenience
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 ... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CREATE DATABASE foo OWNER bar
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)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] CREATE DATABASE foo OWNER bar
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 is that if you want to restore a dump containing objects of multiple ownerships, you need to be superuser; else you can't give away the ownership. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Build-Problem with pgc.c on OSX 10.4
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 reduce my chances of getting that t-shirt ;-) Hum, why don't you just use the CVS directly then? That'd avoid this sort of infelicities. Me, I have never even seen such a t-shirt, so maybe they don't exist. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CREATE DATABASE foo OWNER bar
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's a different issue entirely, which is that if you want to restore a dump containing objects of multiple ownerships, you need to be superuser; else you can't give away the ownership. I guess the issue is that I'd expect public to be owned by the DB Owner after a CREATE DATABASE foo OWNER bar, which would then quiet up the pg_restore since that is the error we get on the public schema. I've remedy'ed the issue with a ALTER SCHEMA, but I think PG ought to do that. LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] IN with arrays
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
quantified comparison predicate ::=
row value constructor comp op quantifier table subquery
quantifier ::= all | some
all ::= ALL
some ::= SOME | ANY
(notice the RHS *must* be a table subquery) whereas IN comes from
in predicate ::=
row value constructor
[ NOT ] IN in predicate value
in predicate value ::=
table subquery
| left paren in value list right paren
in value list ::=
value expression { comma value expression }...
The form expr = ANY (non-query-expr) is therefore a spec extension,
which we are free to define as we wish, and we defined it to be a
scalar-vs-array-elements comparison. But I don't see any way that we
can interpret expr IN (other-expr) as anything except a variant
spelling for a simple equality test.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] What tools do people use to hack on PostgreSQL?
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 completely every few hours, so it wouldn't surprise me that the checked out copy is not compatible with the new repo. I admit I haven't tried. Not a clue. Anyone try it yet? Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] CREATE DATABASE foo OWNER bar
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 template database? If the DBA has installed nondefault permission settings on the public schema or other objects, how do you expect those to be transformed? I do not actually agree with that TODO item, as I think it requires AI-completeness to guess what sorts of changes to apply, and getting ownership/permissions wrong would create a significant risk of security issues. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
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 security policy. This concept may have applicability to other secure operating system such as Trusted Solaris. Just after the announcement, Sun.com's people were interested in SE-PostgreSQL works, and contacted me. They also want to implement a similar functionality on their operating system using Trusted Extension (TX). We got an agreement that a common framework like LSM will be useful to implement and maintain those secure facilities. I want to have a discussion and get feedbacks about this idea from PostgreSQL developers. -- The framework named PGACE(PostgreSQL Access Control Extension). It provides two major facilities. One is hooks on some strategic points. The other is a functionality to associate a tuple with its security attribute. Any hooks is defined as a static inline functions in security/pgace.h. They give no effect, if no security facilities are configured. If SELinux support is enabled via configure script, those definitions are overwritten by security/sepgsql.h, and the hooks calls actual SE-PostgreSQL implementation to provide MAC(mandatory access control). Those hooks are deployed on the some strategic points of PostgreSQL such as simple_heap_insert(), PortalStart() and so on. You can get all the definition of pgace.h and sepgsql.h from the following URL: http://sepgsql.googlecode.com/svn/trunk/src/include/security/ The later functionality enables to associate a tuple with security attribute. It adds a new field (t_security) with Oid type into HeapTupleHeaderData structure. The t_security can persistently hold a Oid of pg_security new system catalog. The pg_security has a combination of Oid value and security attribute with text representation. Database users can refer the attribute via new system column. When SQL query tries to refer this attribute via the system column, PGACE lookups pg_security system column to get a tuple which has same oid compared to t_security value of its HeapTupleHeaderData. It's implemented as input/output handler of new security_label type. The name of system column is defined in pg_config.h.in. In SELinux case, it's named security_context. This system column is writable via UPDATE or INSERT statement, to enables relabeling. Because most of security attribute shares same text representation, this implementation works effectively and economically. As you know, PostgreSQL handles any database object as a tuple stored in system catalogs. So, this concept may have applicability to any kind of database object like table, column and procedure. -- I hope that SE-PostgreSQL and PGACE are merged into future upstreamed PostgreSQL and we can turn on/off by configure option without any patch. I believe any comments and feedbacks are so helpful to indicate the direction of our development with an approach which is acceptable by PostgreSQL development community. Thanks, * Reference The full set of patch is a bit large to post the list directly. (6.7KL) You can checkout the source code from the following URL: http://code.google.com/p/sepgsql/source You can get the patch for SE-PostgreSQL based on PGACE from the following URL: http://sepgsql.googlecode.com/files/sepostgresql-8.2.3-226.patch (against to the stable postgresql-8.2.3) -- KaiGai Kohei [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Build-Problem with pgc.c on OSX 10.4
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 doesn't reduce my chances of getting that t-shirt ;-) Hum, why don't you just use the CVS directly then? That'd avoid this sort of infelicities. git-cvsimport didn't work for me - neither with the main CVS repo, nor with a rsync'ed copy. It complained about all sorts of problems - I don't have enough CVS knowhow to judge if those were actual problems with the repo, or just deficiencies of git-cvsimport. Plus I didn't find a way to import the current version of HEAD as one revision, any only go incrementally from there. It always wanted to mirror the whole history stores in the CVS in my git repo, which is overkill. For SVN, there is git-svn, which does just what I want - I started with some revision a few days ago, and it just incrementally imports updates from there into a special branch of my git repo, and doesn't care about what happened before that revision. It's all not perfect, but I think for me it works better than just doing my changes in a CVS checkout. greetings, Florian Pflug ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What tools do people use to hack on PostgreSQL?
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, the repo is generated completely every few hours, so it wouldn't surprise me that the checked out copy is not compatible with the new repo. I admit I haven't tried. Not a clue. Anyone try it yet? git-svn seems to work fine against the SVN repo, apart from the problem with the files deleted in CVS which still show up in SVN. It's only running for about two days though... greetings, Florian Pflug ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Fix for large file support
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 such. Yes I have it in my patch. I put relsegsize = 0 in the control file when non-segmentation mode is enabled. Zdenek ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
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.
Finally here it is.
What about IDENTITY?
Should it also be part of pg_attrdef? There are two ways
to implement it: have or don't have a notion of it.
The latter would treat GENERATED BY DEFAULT AS IDENTITY
the same as SERIAL.
Is there any good reason to distinguish the two?
Actually, I needed to have a flag for IDENTITY
but not for the reason above. I need it to distinguish
between GENERATED ALWAYS AS IDENTITY
and GENERATED ALWAYS AS ( expr ).
Changes:
- Rewritten the GENERATED/IDENTITY flags to be part of the default
pg_attrdef
This made the patch MUCH smaller.
- SERIALs are now the same as INTEGER GENERATED BY DEFAULT AS IDENTITY
- Allow DROP DEFAULT on GENERATED/IDENTITY columns
- Implemented SET GENERATED ALWAYS AS
- Modified syntax of SET GENERATED {ALWAYS | BY DEFAULT} AS IDENTITY
so it reads as SET IDENTITY GENERATED {ALWAYS | BY DEFAULT}
so compiling gram.y/gram.c doesn't give me errors.
This DDL statement isn't part of SQL:2003 so it might be accepted
as a PostgreSQL extension.
- Modified behaviour of SET IDENTITY to also restore the DEFAULT
expression. Someone might have done did a DROP DEFAULT before
but kept the OWNED sequence.
- Fixed behaviour of GENERATED columns regarding
INSERT ... OVERRIDING SYSTEM VALUE and
only those GENERATED columns get UPDATEd that
are either explicitly modified with SET column = DEFAULT
or one of their referenced columns are modified.
- Testcase and documentation is modified to reflect the above.
- Also allowed UPDATE on IDENTITY columns.
Please, review.
I just realized that by treating SERIAL the same as
IDENTITY GENERATED BY DEFAULT, I incidentally
broke the possibility of multiple SERIALs in the same table.
I rewrote the patch so instead of two BOOL flags,
I now have only one CHAR flag:
- ' ' says it's a simple DEFAULT expression
- 'i' says it's GENERATED ALWAYS AS IDENTITY
- 'g' says it's GENERATED ALWAYS AS ( expr )
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 GENERATED
ALWAYS AS IDENTITY fields? It's just a twisted SERIAL anyway.
And it was said many times that it's not an advantage to blindly
follow the standard.
Also, DROP IDENTITY is equivalent with SET DEFAULT
nextval('owned_sequence') iff the field has an OWNED
sequence and it was GENERATED ALWAYS AS IDENTITY before.
Considering that SERIAL is a macro, and SET/DROP DEFAULT is allowed
on IDENTITY/GENERATED columns per Tom's request,
should I keep this statement?
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/reduce
Is there a good solution to this?
I post the new patch after someone answers those questions for me.
--
--
Zoltán Böszörményi
Cybertec Geschwinde Schönig GmbH
http://www.postgresql.at/
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
[HACKERS] Why xlog stuff is done after the filetruncate op in smgrtruncate?
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 smgrtruncate; kill postmaster before smgrtruncate do xlog stuff(set a breakpoint before xlog stuff); 5. startup database the 3rd time, during the recovery, the database will crash with: PANIC: WAL contains references to invalid pages ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Hacking on PostgreSQL via GIT
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 doing (writing patches that you'll want to be rebasing onto the latest HEAD for merging later) git is probably the best tool. That's what I use it for... tracking my experimental / custom branches of projects that use CVS or SVN :-) Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a daily import for you - once that's in place you can probably get a repo with your work on http://repo.or.cz/ cheers, martin -- --- Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017 Make things as simple as possible, but no simpler - Einstein --- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
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 GENERATED
ALWAYS AS IDENTITY fields? It's just a twisted SERIAL anyway.
I don't see the value of disallowing it.
Also, DROP IDENTITY is equivalent with SET DEFAULT
nextval('owned_sequence') iff the field has an OWNED
sequence and it was GENERATED ALWAYS AS IDENTITY before.
Considering that SERIAL is a macro, and SET/DROP DEFAULT is allowed
on IDENTITY/GENERATED columns per Tom's request,
should I keep this statement?
If it's not in the spec I don't see any strong reason to have it...
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/reduce
You'll have to fix that. Usually you can get around it by making the
grammar a bit more verbose --- if you were trying to avoid duplication
by means of optional productions, don't do that.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Hacking on PostgreSQL via GIT
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) ;-) For the kind of work you'll be doing (writing patches that you'll want to be rebasing onto the latest HEAD for merging later) git is probably the best tool. That's what I use it for... tracking my experimental / custom branches of projects that use CVS or SVN :-) Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a daily import for you - once that's in place you can probably get a repo with your work on http://repo.or.cz/ 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.git Note that this is a special conversion - I intentionally unmunge all the $PostgreSQL$ tags in this repo. I hate the Keyword expansion, and it only servers to make otherwise automatically merging a manual process. So I specifically go through and un-munge any keyword a-like things before stomping it into GIT. For those interested int he conversion process, I've used a slightly modified version of fromcvs (A ruby cvs to git/Hg tool), and it runs on all of pgsql in about 20 minutes. I gave up on git-svn (because of both speed and my in-ablility to easy filter out Keywords, etc) and git-cvsimport (because cvsps doesn't seem to like pgsql's repo) I update the git repo daily, based on an anonymous rsync of the cvsroot. If the anon-rsync is updated much more frequently, and people think my git conversion should match it, I have no problem having cron run it more than daily. Also - note that I give *no* guarentees of it's integrity, etc. 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/preproc/pgc.c | 2887 ++ interfaces/ecpg/preproc/preproc.c |16988 ++ And at this point, I haven't been bothered to see where those files came from (and where they dissapear) in CVS and why my import isn't picking that up... I could probably be pushed if others find this repo really useful, but those files problematic... ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
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 multiple GENERATED
ALWAYS AS IDENTITY fields? It's just a twisted SERIAL anyway.
I don't see the value of disallowing it.
I thought so.
Also, DROP IDENTITY is equivalent with SET DEFAULT
nextval('owned_sequence') iff the field has an OWNED
sequence and it was GENERATED ALWAYS AS IDENTITY before.
Considering that SERIAL is a macro, and SET/DROP DEFAULT is allowed
on IDENTITY/GENERATED columns per Tom's request,
should I keep this statement?
If it's not in the spec I don't see any strong reason to have it...
It's not. Removed.
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/reduce
You'll have to fix that. Usually you can get around it by making the
grammar a bit more verbose --- if you were trying to avoid duplication
by means of optional productions, don't do that.
What do you mean by making it more verbose?
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 was
to disallow this in the grammar.
BTW, thanks for the quick answer.
--
--
Zoltán Böszörményi
Cybertec Geschwinde Schönig GmbH
http://www.postgresql.at/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Hacking on PostgreSQL via GIT
* 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 hate the Keyword expansion, and it only servers to make otherwise automatically merging a manual process. So I specifically go through and un-munge any keyword a-like things before stomping it into GIT. Expect it to change in the next little while once more ;-) a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Hacking on PostgreSQL via GIT
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 - I'm new to git, so I really appreciate any help that I can get. For the kind of work you'll be doing (writing patches that you'll want to be rebasing onto the latest HEAD for merging later) git is probably the best tool. That's what I use it for... tracking my experimental / custom branches of projects that use CVS or SVN :-) Thats how I figured I'd work - though I don't yet understand what the advantage of rebase is over merge. Currently, I've setup a git repo that pulls in the changes from the SVN repo, and pushed them to my main soc git repo. On that main repo I have two branches, master and pgsql-head, and I call cg-merge pgsql-head if I want to merge with CVS HEAD. Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a daily import for you - once that's in place you can probably get a repo with your work on http://repo.or.cz/ Having a git mirror of the pgsql CVS would be great. BTW, I've just check out repo.or.cz, and noticed that there is already a git mirror of the pgsql CVS: http://repo.or.cz/w/PostgreSQL.git greetings + thanks Florian Pflug ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Hacking on PostgreSQL via GIT
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.git Ah - thats what I just stumbled over ;-) For those interested int he conversion process, I've used a slightly modified version of fromcvs (A ruby cvs to git/Hg tool), and it runs on all of pgsql in about 20 minutes. I gave up on git-svn (because of both speed and my in-ablility to easy filter out Keywords, etc) and git-cvsimport (because cvsps doesn't seem to like pgsql's repo) Yeah, git-cvsimport didn't work for me either... I update the git repo daily, based on an anonymous rsync of the cvsroot. If the anon-rsync is updated much more frequently, and people think my git conversion should match it, I have no problem having cron run it more than daily. Also - note that I give *no* guarentees of it's integrity, etc. 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/preproc/pgc.c | 2887 ++ interfaces/ecpg/preproc/preproc.c |16988 ++ And at this point, I haven't been bothered to see where those files came from (and where they dissapear) in CVS and why my import isn't picking that up... I could probably be pushed if others find this repo really useful, but those files problematic... Thats interesting - the SVN mirror of the pgsql CVS at http://projects.commandprompt.com/public/pgsql/browser has exactly the same problem with those 3 files, as I found out the hard way ;-) In the case of pgc.c, I've compared that revisions in CVS with the one in SVN. SVN include the cvs-version 1.5 if this file in trunk, which seems to be the last version of that file in CVS HEAD. Interestingly, http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c shows no trace of the file being deleted from HEAD either - it just shows that it was removed from WIN32_DEV. But still a CVS checkout doesn't include that file... Since 3 tools (cvsweb, git-cvsimport and whatever commandprompt uses to create the SVN mirror) all come to the same conclusion regarding this file, I think that this is caused by some corruption of the CVS repository - but I don't have the cvs-fu to debug this... greetings, Florian Pflug ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
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 was to disallow this in the grammar. I think you probably want a more specific error message than syntax error for that, so the right thing to do is complain in code rather than try to make the grammar per se not have a production that accepts it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Hacking on PostgreSQL via GIT
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/preproc/pgc.c | 2887 ++ interfaces/ecpg/preproc/preproc.c |16988 ++ And at this point, I haven't been bothered to see where those files came from (and where they dissapear) in CVS and why my import isn't picking that up... I could probably be pushed if others find this repo really useful, but those files problematic... 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) like preproc.h are not showing up. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
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/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 conflicts - maybe that helps to figure out their exact cause, and to find a workaround. greetings, Florian Pflug ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vista/IPv6
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? I don't have IPV6 test environment recently However, It has the compile environment of VC6, and it is finished finely. Then, win32.mak is not the thing of only VC6. And VC 7.1, VC8, and they will be used. It should be then supported IPV6 at least. What confirmed #DEFINE of IPV6 and built it by VC6 has passed the test of IPV4 further again. Therefore, you should make it effective. I have applied a change for this. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
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 conflicts - maybe that helps to figure out their exact cause, and to find a workaround. You can almost always get rid of shift/reduce conflicts by unwinding some of the productions - resist the temptation to factor the grammar. The effect of this is to eliminate places where the parser has to decide between shifting and reducing. (This is why, for example, almost all the drop foo if exists variants require separate productions rather than using opt_if_exists.) cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Hacking on PostgreSQL via GIT
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) like preproc.h are not showing up. The weird thing about these files is that the CVS history shows commits on HEAD later than the file removal commit. I don't recall if Vadim unintentionally re-added the files before making those commits ... but if he did, you'd think it'd have taken another explicit removal to get rid of them in HEAD. More likely, there was some problem in his local tree that allowed a cvs commit to think it should update the repository with copies of the derived files he happened to have. 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 definition. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Adjusting index special storage for pg_filedump's convenience
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 release or two. We've also been talking about setting hint bits and doing some kind of retail vacuuming in bgwriter with HOT. To do that, we need to identify heap pages in the bgwriter. While heap pages can currently be identified by the fact that they don't have a special area, it feels hackish, and we might want to do something like that for index pages too in the future. We now have a 16-bit pd_flags field in the page header. We could use a few bits from that. +1 or add one extra field Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Why xlog stuff is done after the filetruncate op in smgrtruncate?
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 in deep trouble because WAL replay will try to do the truncate and likewise fail, preventing the system from restarting. Other non-rollbackable filesystem ops (I think just CREATE/DROP DATABASE/TABLESPACE) are done the same way. CREATE DATABASE would be particularly nasty to reverse the order for, since there are obvious cases like out-of-disk-space that will make it fail. 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 smgrtruncate; kill postmaster before smgrtruncate do xlog stuff(set a breakpoint before xlog stuff); 5. startup database the 3rd time, during the recovery, the database will crash with: PANIC: WAL contains references to invalid pages Hmm. Maybe we need something like xlog a tentative truncate, do it, xlog real truncate? The tentative truncate would merely tell replay not to be surprised if those blocks aren't there anymore. Seems a bit grotty though. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Hacking on PostgreSQL via GIT
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 the past) like preproc.h are not showing up. The weird thing about these files is that the CVS history shows commits on HEAD later than the file removal commit. I don't recall if Vadim unintentionally re-added the files before making those commits ... but if he did, you'd think it'd have taken another explicit removal to get rid of them in HEAD. More likely, there was some problem in his local tree that allowed a cvs commit to think it should update the repository with copies of the derived files he happened to have. 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 definition. The question is if it'd be acceptable to manually remove that last commit from the repository. I guess simply readding, and then removing the files again should do the trick, though I'd be cleaner to fix remove the offending commit in the first place. Should postgres ever decide to switch to another version control system (which I don't advocate), that'd be one obstacle less to deal with... Or is the risk of causing breakage too high? greetings, Florian Pflug ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
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 information about those conflicts - maybe that helps to figure out their exact cause, and to find a workaround. You can almost always get rid of shift/reduce conflicts by unwinding some of the productions - resist the temptation to factor the grammar. The effect of this is to eliminate places where the parser has to decide between shifting and reducing. (This is why, for example, almost all the drop foo if exists variants require separate productions rather than using opt_if_exists.) cheers andrew Thanks. This idea solved one of the two shift/reduce conflicts. But the other one can only be solved if I put GENERATED into the reserved_keyword set. But the standard spec says it's unreserved. Now what should I do with it? Best regards, Zoltán ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- -- Zoltán Böszörményi Cybertec Geschwinde Schönig GmbH http://www.postgresql.at/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Build-Problem with pgc.c on OSX 10.4
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 root problem is that the CVS repository is in a strange state, I believe. The RCS file Attic/pgc.c,v has following metadata for the most recent revision of the file: 1.5 date99.06.29.04.54.48; author vadim; state Exp; branches 1.5.2.1; next1.4; AFAICS this is wrong: the file should be deleted and is in Attic/, so it should have state dead; (which is the state that most of the deleted files have for their last revision). preproc.c,v has the same error -- you could check for other files with the same problem by diff'ing a fresh checkout from SVN with the same result from CVS. (Was this never done?) I think the right fix is for someone with shell access to the CVS master to manually move ecpg/Attic/pgc.c,v to ecpg/pgc.c,v, do a fresh CVS checkout/update, and then cvs delete pgc.c. Similarly for preproc.c,v. -Neil ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Hacking on PostgreSQL via GIT
[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 here (being one of the git-cvsimport maintainers) ;-) Cool - I'm new to git, so I really appreciate any help that I can get. For the kind of work you'll be doing (writing patches that you'll want to be rebasing onto the latest HEAD for merging later) git is probably the best tool. That's what I use it for... tracking my experimental / custom branches of projects that use CVS or SVN :-) Thats how I figured I'd work - though I don't yet understand what the advantage of rebase is over merge. Currently, I've setup a git repo that pulls in the changes from the SVN repo, and pushed them to my main soc git repo. On that main repo I have two branches, master and pgsql-head, and I call cg-merge pgsql-head if I want to merge with CVS HEAD. Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a daily import for you - once that's in place you can probably get a repo with your work on http://repo.or.cz/ Having a git mirror of the pgsql CVS would be great. BTW, I've just check out repo.or.cz, and noticed that there is already a git mirror of the pgsql CVS: http://repo.or.cz/w/PostgreSQL.git This strikes me as being a really super thing, having both Subversion and Git repositories publicly available that are tracking the PostgreSQL sources. Stepping back to the SCM discussion, people were interested in finding out what merits there were in having these sorts of SCMs, and in finding out what glitches people might discover (e.g. - like the files where the CVS repository is a bit schizophrenic as to whether they are still there or not...). Having these repositories should allow some of this experimentation to take place now. I'd be interested in fiddling with a Git repository, at some point; I'll happily wait a bit to start drawing from one of these existing ones, to let the dust settle and to let things stabilize a bit. -- (reverse (concatenate 'string moc.enworbbc @ enworbbc)) http://linuxdatabases.info/info/emacs.html Support your local medical examiner - die strangely. -- Blake Bowers ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Hacking on PostgreSQL via GIT
[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 +++ interfaces/ecpg/preproc/pgc.c | 2887 ++ interfaces/ecpg/preproc/preproc.c |16988 ++ And at this point, I haven't been bothered to see where those files came from (and where they dissapear) in CVS and why my import isn't picking that up... I could probably be pushed if others find this repo really useful, but those files problematic... Those three files are normally generated by either flex or bison (gram.c depends on gram.y, pgc.c on pgc.l, and preproc.c on preproc.y); I'd suggest removing those three files from your git repository. -- cbbrowne,@,acm.org http://cbbrowne.com/info/rdbms.html They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown. -- Carl Sagan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Hacking on PostgreSQL via GIT
* 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 definition. ;-) Would anyone know if these were hand moved to Attic? For instance, I *can't* seem to get non-dead files into Attic, no matter what I try with my cvs (on debian). But I haven't gone through the last 8 years of CVS's CVS logs to see if they fixed a bug in the cvs server code that would allow a non-dead HEAD rcs to be in the Attic... The question is if it'd be acceptable to manually remove that last commit from the repository. I guess simply readding, and then removing the files again should do the trick, though I'd be cleaner to fix remove the offending commit in the first place. Should postgres ever decide to switch to another version control system (which I don't advocate), that'd be one obstacle less to deal with... Or is the risk of causing breakage too high? Well, I've hand fixed this in my conversion process so my git conversion should not have this problem... I'm not a fan of mucking around by hand in CVS. It's only because of the short comings of CVS that it's necessary to every resort to that. So I don't think re-adding/deleting it is worth it... I've updated the repo.or.cz/PostgreSQL.git again - and this time it should be pretty good. Consider it usable to clone off and follow CVS development with... I won't re-convert the whole thing again, and will just provide daily updates to it now. Unless anybody finds issues with it... Ignore the public branch in there - that got in in an errant push, and I don't know how to remove branches on repo.or.cz. I'm now just putting conversion notes up in the public branch... IT's *not* a PostgreSQL branch. a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Hacking on PostgreSQL via GIT
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 and then re-removing the files on HEAD. Does anyone think that poses any real risk? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
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? What's more, we have a SoC project for column level access controls. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RESET command seems pretty disjointed now
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 etc might be more intuitive than extending
RESET?
DISCARD PLANS and DISCARD TEMP seem pretty reasonable, but DISCARD SESSION
sounds a bit odd --- it seems like it might mean disconnect, which of
course is exactly what we're trying to avoid. But possibly we could
rename RESET SESSION as DISCARD ALL.
Leastwise I haven't got any better ideas. Anyone have another proposal?
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Hacking on PostgreSQL via GIT
* 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 bug involved *somewhere*. 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, when trying to figure out how they got that way in the first place... What I did when I converted the repo was just hand edit those files to have a state of dead to match their position in Attic for those RCS revs. If you add them and remove them, I believe my GIT conversion will actually follow that correctly... If not - I just rm -Rf it and let it go from scratch one more time... I'm glad computers are good at that type of repetitive task... a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
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 was the bit about being able to assign to a system column in INSERT or UPDATE. I'm fairly sure that that would take some *significant* redesign of querytree and plan targetlist representation :-( ... I looked at it once for OIDs and decided it wasn't worth the trouble. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
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 infrastructure might be seen as a plus, but I'm not sure the rest of the world would be pleased. There are also some interesting questions about SQL spec compliance and whether a database that silently hides some rows from you will give semantically consistent results. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] RESET command seems pretty disjointed now
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 etc might be more intuitive than extending
RESET?
DISCARD PLANS and DISCARD TEMP seem pretty reasonable, but DISCARD SESSION
sounds a bit odd --- it seems like it might mean disconnect, which of
course is exactly what we're trying to avoid. But possibly we could
rename RESET SESSION as DISCARD ALL.
Leastwise I haven't got any better ideas. Anyone have another proposal?
What about
RESET parameter
RESET { PLANS | TEMP | TEMPORARY }
RESET ALL { PARAMETERS | STATE }
RESET ALL would become an abbreviation of RESET ALL PARAMETERS (for backwards
compatibility), while RESET SESSION would be renamed to RESET ALL STATE.
greetings, Florian Pflug
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] RESET command seems pretty disjointed now
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 abbreviation of RESET ALL PARAMETERS (for backwards
compatibility), while RESET SESSION would be renamed to RESET ALL STATE.
This doesn't do anything to address the lack of coherence. It's not
only that backward compatibility forces us to break the clear meaning of
ALL; another problem is that we break the symmetry between SET, RESET,
and SHOW. If you can RESET SESSION, what does it mean to SET SESSION?
Or SHOW SESSION?
Given the precedent that RESET ALL only resets GUC variables, I think
it's probably best if we just say that RESET only affects GUC variables,
period. The new functionality should go by another name entirely.
I'm not wedded to DISCARD by any means, but I do not believe that
changing some words after RESET is going to fix my complaint.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Hacking on PostgreSQL via GIT
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, when trying to figure out how they got that way in the first place... Well, it doesn't work :-(. CVS is definitely a bit confused about the status of these files: $ touch gram.c $ cvs add gram.c cvs add: gram.c added independently by second party $ cvs remove gram.c cvs remove: file `gram.c' still in working directory cvs remove: 1 file exists; remove it first $ rm gram.c rm: remove regular empty file `gram.c'? y $ cvs remove gram.c cvs remove: nothing known about `gram.c' 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? I have login on cvs.postgresql.org and can try this, but I'd like confirmation from someone that this is unlikely to break things. Is there any hidden state to be fixed in the CVS repository? I don't see any ... regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Hacking on PostgreSQL via GIT
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 hopefully it's all cleaned up now --- at least the states of the files look reasonable in cvsweb. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Hacking on PostgreSQL via GIT
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 trying to create an Attic with, when trying to figure out how they got that way in the first place... Well, it doesn't work :-(. CVS is definitely a bit confused about the status of these files: $ touch gram.c $ cvs add gram.c cvs add: gram.c added independently by second party $ cvs remove gram.c cvs remove: file `gram.c' still in working directory cvs remove: 1 file exists; remove it first $ rm gram.c rm: remove regular empty file `gram.c'? y $ cvs remove gram.c cvs remove: nothing known about `gram.c' 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? I have login on cvs.postgresql.org and can try this, but I'd like confirmation from someone that this is unlikely to break things. Is there any hidden state to be fixed in the CVS repository? I don't see any ... Forgive my caution, but I'd suggest trying on a copy first. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)
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/soc/postgres/appinfo.html?csaid=E272DA8E6521568F For people who are already using SELinux or Trusted Solaris, making the database dependent on that infrastructure might be seen as a plus, but I'm not sure the rest of the world would be pleased. Even where SELinux is available it has had mixed reviews - I habitually disable it. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Hacking on PostgreSQL via GIT
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? I have login on cvs.postgresql.org and can try this, but I'd like confirmation from someone that this is unlikely to break things. Is there any hidden state to be fixed in the CVS repository? I don't see any ... Forgive my caution, but I'd suggest trying on a copy first. Too late ;-) FWIW my CVSup copy seems happy with the change; it reported this when I updated it: $ pgcvsup Connected to cvsup.postgresql.org Updating collection repository/cvs Edit pgsql/src/backend/parser/gram.c,v - Attic Edit pgsql/src/backend/utils/mb/encnames.c,v Edit pgsql/src/bin/pg_dump/pg_dump.c,v Edit pgsql/src/bin/psql/common.c,v Edit pgsql/src/include/pg_config.h.win32,v Edit pgsql/src/interfaces/ecpg/preproc/pgc.c,v - Attic Edit pgsql/src/interfaces/ecpg/preproc/preproc.c,v - Attic Edit pgsql/src/tools/msvc/Solution.pm,v Rsync sup/repository/checkouts.cvs Finished successfully The gram.c,v file looks good -- it has the expected state dead; line. A checked out tree from that updates fine. A cvs update to a checked out tree direct from the main CVS server also updates fine. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Hacking on PostgreSQL via GIT
* 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 then I could commit and cvs remove and commit again. So hopefully it's all cleaned up now --- at least the states of the files look reasonable in cvsweb. And my GIT conversion handled that nicely too. Looks good (at least from the GIT PoV). 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 Tom's first commit will truncate them (because he checked them in as empty files), and the 2nd commit will remove them again. So it's still a gotcha if you're trying to get a copy of CVS from ages ago via one of the alternative SCM conversions... But my git one works, so I'll let others worry about the others ;-) a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Hacking on PostgreSQL via GIT
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 Tom's first commit will truncate them (because he checked them in as empty files), and the 2nd commit will remove them again. So it's still a gotcha if you're trying to get a copy of CVS from ages ago via one of the alternative SCM conversions... 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. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Hacking on PostgreSQL via GIT
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 repository dates, but a svn checkout will use the current time unless you enable a config option for your local svn client. Kris Jurka ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
