KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
I don't provide both of security_label and security_acl
system columns for system/user tables.
I didn't write it explicitly, it might make you confusing.
User cannot see what security label is assigned to them
due to lack of system column,
On Tue, 2009-01-27 at 13:06 +0100, Zdenek Kotala wrote:
Space reservation MUST TO be implemented if we
want to have 8.4-8.5 upgrade.
Why not just add a few dummy columns onto each catalog table? If we need
space to expand a row we can just drop one of the dummy columns from the
new catalog
On Fri, 2009-01-30 at 13:15 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
I'm thinking to add a new function that will allow crash testing easier.
pg_crash_standby() will issue a new xlog record, XLOG_CRASH_STANDBY,
which when replayed will just throw a FATAL error and crash
On Fri, 2009-01-30 at 13:25 +0200, Heikki Linnakangas wrote:
That whole area was something I was leaving until last, since
immediate
shutdown doesn't work either, even in HEAD. (Fujii-san and I
discussed
this before Christmas, briefly).
We must handle shutdown gracefully, can't just
On Fri, 2009-01-30 at 16:55 +0200, Heikki Linnakangas wrote:
Ok, here's an attempt to make shutdown work gracefully.
Startup process now signals postmaster three times during startup: first
when it has done all the initialization, and starts redo. At that point.
postmaster launches
Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
I don't provide both of security_label and security_acl
system columns for system/user tables.
I didn't write it explicitly, it might make you confusing.
User cannot see what security label is assigned to them
due
Peter Eisentraut wrote:
On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote:
well from a quick glance there is the bugzilla demo install as well as
pieces of reviewboard and patchwork on the trackerdemo jail.
So what's the URL and where can we sign up?
resurrected the install
On Sat, Jan 31, 2009 at 4:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2009-01-27 at 13:06 +0100, Zdenek Kotala wrote:
Space reservation MUST TO be implemented if we
want to have 8.4-8.5 upgrade.
Why not just add a few dummy columns onto each catalog table? If we need
space to
Tom Lane wrote:
Okay, another question --- there are two places in pg_backup_custom.c
where the patch #ifdef's out hasSeek tests on WIN32. Why is that?
If checkSeek() is wrong on Windows, wouldn't it be better to fix it?
Oh, dear. That's a hangover from before that got fixed
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Stephen Frost wrote:
I think Bruce's question was where you stored the security_acl and
security_label columns. Based on your response (and a bit of purusal
through the code.google site), it looks like you still have security_acl
and
I just noticed these warnings on pgevent/mingw. I guess we've probably
been living with it for years, but it would be nice to get it clean.
(There are also some similar warnings earlier in the build regarding
RegisterWaitForSingleObject.)
dllwrap --def pgevent.def -o pgevent.dll pgevent.o
On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost sfr...@snowman.net wrote:
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Stephen Frost wrote:
I think Bruce's question was where you stored the security_acl and
security_label columns. Based on your response (and a bit of purusal
through the
Andrew Dunstan wrote:
I just noticed these warnings on pgevent/mingw. I guess we've probably
been living with it for years, but it would be nice to get it clean.
(There are also some similar warnings earlier in the build regarding
RegisterWaitForSingleObject.)
dllwrap --def pgevent.def -o
I think what people
are looking for, instead, is either additional columns to just the
existing system tables that need them (eg: pg_class, pg_attribute) or
included in the existing ACL structure (the aclitem structure). Another
option might be a seperate set of tables.
It should not be
Robert Haas wrote:
On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost sfr...@snowman.net wrote:
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Stephen Frost wrote:
I think Bruce's question was where you stored the security_acl and
security_label columns. Based on your response (and a bit of purusal
Hi.
dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o
Warning: resolving _DllUnregisterServer by linking to
_dllunregisterser...@0
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving _DllRegisterServer by
Hiroshi Saito wrote:
Hi.
dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o
Warning: resolving _DllUnregisterServer by linking to
_dllunregisterser...@0
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving
What is expected for collation and ctype settings on Windows when we
specify utf8 as the encoding and en_US.utf8 as the locale?
I am seeing them set to English_United States.1252.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Simon Riggs escreveu:
On Tue, 2009-01-27 at 13:06 +0100, Zdenek Kotala wrote:
Space reservation MUST TO be implemented if we
want to have 8.4-8.5 upgrade.
Why not just add a few dummy columns onto each catalog table? If we need
space to expand a row we can just drop one of the dummy
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Eventually does the crash come from the call SetEnvironemntVariable
(.., NULL) on mingw-XP(or older?)?
I'm also interested in this issue and want to know the cause.
The debugger shows that we actually fail on a popen() call in intdb.
Hiroshi Inoue wrote:
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
Magnus Hagander wrote:
Are we *sure*, btw, that this is actually a mingw issue, and not
something else in the environment? Could you try a MSVC compiled
binary
on the
Hi.
Sorry, I was not able to find the point to which you point.
This appears to be exactly what you are *not* supposed to do. Which is
assign an ordinal. See:
http://msdn.microsoft.com/en-us/library/8e705t74(VS.71).aspx
(that's just about the warning, there is a page somewhere with more
On Sat, Jan 31, 2009 at 01:28:58PM -0200, Euler Taveira de Oliveira wrote:
The problem is: how much space do we need at each catalog table? Suppose that
after 2 releases we need x + 1 bytes per tuple but we only foresaw x bytes; so
we need to deprecate support for this version and advise DBA
Hi.
Well, XP only does it when it's built with mingw!
Or is this actually dependent on if the binary is run under msys or cmd?
Both they look at a problem.
http://winpg.jp/~saito/pg_bug/20090124/
Then, If SetEnvironmentVariable of Andrew-san point is removed,
a problem will clearvery
Andrew Dunstan wrote:
Tom Lane wrote:
Okay, another question --- there are two places in pg_backup_custom.c
where the patch #ifdef's out hasSeek tests on WIN32. Why is that?
If checkSeek() is wrong on Windows, wouldn't it be better to fix it?
Oh, dear. That's a hangover from before
Magnus Hagander wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Eventually does the crash come from the call SetEnvironemntVariable
(.., NULL) on mingw-XP(or older?)?
I'm also interested in this issue and want to know the cause.
The debugger shows that we actually fail on
IANAC, but that's my impression too. The simplified patch shouldn't
assume that row-level security in its current form is going to end up
getting put back in. AFAICS, there's no reason why the security ID
for tables can't be a regular attribute in pg_class, or why the
security attribute for
Hey folks,
I am trying to add GRANT SELECT ON ALL TABLES to postgres, as it has
been quite few times now - where I had to write a procedure for that.
I kind of looked around, and more or less know how to approach it. But
I am stuck on parser :), yes - parser.
Can someone walk me through
Ofcourse, the simplest way to me for handling type changes seems to be
to keep the old type OID reserved and have the new version of the type
with a new OID. Then the entire problem vanishes. But it was decided a
long time ago not to do that.
Why was that decision made? Suppose you have a
On 31 Jan 2009, at 16:46, Grzegorz Jaskiewicz wrote:
+ {table, TABLES, RESERVED_KEYWORD},
Gaaah, a typo...
:(
(another useless post to -hackers, by myself).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
You're going to kick yourself, but:
{table, TABLE, RESERVED_KEYWORD},
+ {table, TABLES, RESERVED_KEYWORD},
^
I don't see any reason offhand why it should have to be a reserved word
though. You should be able to make
On Sat, Jan 31, 2009 at 04:46:26PM +, Grzegorz Jaskiewicz wrote:
Hey folks,
I am trying to add GRANT SELECT ON ALL TABLES to postgres,
Is this part of the SQL:2008? If not, is there something else that
is?
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415
On 31 Jan 2009, at 17:17, Gregory Stark wrote:
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
You're going to kick yourself, but:
{table, TABLE, RESERVED_KEYWORD},
+ {table, TABLES, RESERVED_KEYWORD},
^
I don't see any reason offhand why it should have to
from http://wiki.postgresql.org/wiki/Todo:
[E] inline: 10px-UntickedTick.svg.pngAllow GRANT/REVOKE permissions to be applied to all schema objects
with one command
The proposed syntax is: GRANT SELECT ON ALL TABLES IN public TO
phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser;
On Sat, Jan 31, 2009 at 05:24:15PM +, Grzegorz Jaskiewicz wrote:
from http://wiki.postgresql.org/wiki/Todo:
I see the TODO item, but I don't see anything in the SQL standard,
which I think is something we should explore before making a
potentially incompatible change.
Cheers,
David.
--
Grzegorz Jaskiewicz wrote:
from http://wiki.postgresql.org/wiki/Todo:
[E]
Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command
The proposed syntax is: GRANT SELECT ON ALL TABLES IN public
Andrew Dunstan wrote:
Even weirder. It has now started working. For no apparent reason. I am
seriously confused.
I spoke too soon :-(
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dawn_batdt=2009-01-31%2016:28:16
cheers
andrew
--
Sent via pgsql-hackers mailing list
On 31 Jan 2009, at 17:30, Andrew Dunstan wrote:
But the syntax you posted does not do this at all. Where does it
restrict the grant to a single schema, like the syntax above?
I am just starting the attempt here, obviously since I admit that my
parser skills are next to none - I didn't
On 31 Jan 2009, at 17:28, David Fetter wrote:
On Sat, Jan 31, 2009 at 05:24:15PM +, Grzegorz Jaskiewicz wrote:
from http://wiki.postgresql.org/wiki/Todo:
I see the TODO item, but I don't see anything in the SQL standard,
which I think is something we should explore before making a
Robert Haas wrote:
People who upgrade via pg_dump will automatically get the new and
improved widget type because that is what is now called widget. But
people who in-place upgrade will end up with the old_shitty_widget
type. Then you just run some dead simple postupdate script that goes
Robert Haas wrote:
Ofcourse, the simplest way to me for handling type changes seems to be
to keep the old type OID reserved and have the new version of the type
with a new OID. Then the entire problem vanishes. But it was decided a
long time ago not to do that.
Why was that decision made?
On 1/31/09, Magnus Hagander mag...@hagander.net wrote:
Hiroshi Saito wrote:
Hi.
dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o
Warning: resolving _DllUnregisterServer by linking to
_dllunregisterser...@0
Use --enable-stdcall-fixup to disable these warnings
Simon Riggs wrote:
On Fri, 2009-01-30 at 13:15 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
I'm thinking to add a new function that will allow crash testing easier.
pg_crash_standby() will issue a new xlog record, XLOG_CRASH_STANDBY,
which when replayed will just throw a FATAL error
Simon Riggs wrote:
On Fri, 2009-01-30 at 16:55 +0200, Heikki Linnakangas wrote:
Ok, here's an attempt to make shutdown work gracefully.
Startup process now signals postmaster three times during startup: first
when it has done all the initialization, and starts redo. At that point.
postmaster
On Jan 31, 2009, at 2:44 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com
wrote:
Robert Haas wrote:
People who upgrade via pg_dump will automatically get the new and
improved widget type because that is what is now called widget. But
people who in-place upgrade will end up with
Zdenek Kotala wrote:
PL-check gives the diff below on PLTCL tests under en_US locale. I guess
the simplest answer is to add an alternative result file.
Yes, I thought about add locale suffix for alternative result file, but
it could be useless overhead.
But some tests can be modified.
Howdy,
Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:
http://justatheory.com/computers/databases/postgresql/dynamic-limit.html
Thanks,
David
--
Sent via pgsql-hackers
On 1/31/09, Marko Kreen mark...@gmail.com wrote:
On 1/31/09, Magnus Hagander mag...@hagander.net wrote:
Hiroshi Saito wrote:
Hi.
dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o
Warning: resolving _DllUnregisterServer by linking to
_dllunregisterser...@0
On Sat, Jan 31, 2009 at 05:40:57PM +, Grzegorz Jaskiewicz wrote:
On 31 Jan 2009, at 17:30, Andrew Dunstan wrote:
But the syntax you posted does not do this at all. Where does it
restrict the grant to a single schema, like the syntax above?
I am just starting the attempt here, obviously
On 1 Feb 2009, at 00:05, Joshua Tolley wrote:
to add new syntax, you might consider writing a function instead. This
function might take parameters such as the privilege to grant and
the user to
grant it to, and be called something like this:
SELECT my_grant_function('someuser',
On 31 Jan 2009, at 17:17, Gregory Stark wrote:
I don't see any reason offhand why it should have to be a reserved
word
though. You should be able to make it an UNRESERVED_KEYWORD. Oh, and
you'll
want to add it to the list of tokens in unreserved_keyword in gram.y
as well.
removing it
On 31 Jan 2009, at 17:22, David Fetter wrote:
Is this part of the SQL:2008? If not, is there something else that
is?
As far as I can see in the 'free' draft, no. Which is quite funny, cos
'DATABASE' keyword isn't there too..
Anyway. Looks like m$'s sybase clone got it, so I figure - at
Hi.
I am checking that consider sufficient test as Marko-san and it is satisfactory.
However, That there is a portion which does not suit the solution of MSVC
also understands. Therefore, How is this proposal?
1. )remove pgevent.def
It is always generated.
2.) improvement of the Makefile
Grzegorz Jaskiewicz wrote:
On 31 Jan 2009, at 17:22, David Fetter wrote:
Is this part of the SQL:2008? If not, is there something else that
is?
As far as I can see in the 'free' draft, no. Which is quite funny, cos
'DATABASE' keyword isn't there too..
Anyway. Looks like m$'s sybase
Robert Haas wrote:
IANAC, but that's my impression too. The simplified patch shouldn't
assume that row-level security in its current form is going to end up
getting put back in. AFAICS, there's no reason why the security ID
for tables can't be a regular attribute in pg_class, or why the
Ooops, sorry., One mistake:-(
Please this.
- Original Message -
From: Hiroshi Saito z-sa...@guitar.ocn.ne.jp
Hi.
I am checking that consider sufficient test as Marko-san and it is satisfactory.
However, That there is a portion which does not suit the solution of MSVC
also
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
One melancholic thing is adding a member into pg_proc.
It defines more than 2000 of entries which I have to modify correctly. :(
Is there any script to help it?
Not that I'm aware of.. You might be able to create an appropriate
regex though, esp. if
KaiGai Kohei wrote:
One melancholic thing is adding a member into pg_proc.
It defines more than 2000 of entries which I have to modify correctly. :(
Is there any script to help it?
Last time I added a column to a large catalog, I used a perl script to
help me, IIRC, but I haven't kept
Andrew Dunstan wrote:
KaiGai Kohei wrote:
One melancholic thing is adding a member into pg_proc.
It defines more than 2000 of entries which I have to modify correctly. :(
Is there any script to help it?
Last time I added a column to a large catalog, I used a perl script to
help me,
Ahh, sorry..like the spam
again!
I thought over that the existing msvc the did not have uneasines.
so, I wish to make it this as correspondence with worried Magnus-san.
It is after sufficient test.
Regards,
Hiroshi Saito
- Original Message -
From: Hiroshi Saito
I've been doing some benchmarking and profiling on the PostgreSQL
query analyzer, and it seems that (at least for the sorts of queries
that I typically run) the dominant cost is add_path(). I've been able
to find two optimizations that seem to help significantly:
1. add_path() often calls
On 23 Jan 2009, at 00:03, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
Seeing this list reminded me of a pet-peeve.. \du and \dg actually
show
the same info, that's fine, but neither of them show the rolcanlogin
value.
+1 for fixing that.
was it that easy, or I got it
62 matches
Mail list logo
