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
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
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.
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
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
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
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
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
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
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 ...
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)---
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
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
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
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 ::=
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
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
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
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
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
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
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.
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
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
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
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) ;-)
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
* 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
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 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
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
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 +++
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
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
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
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
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
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
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
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
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
[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
[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 +++
* 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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
* 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
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
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
62 matches
Mail list logo
