On 23 Jan 2009, at 00:03, Tom Lane wrote:
Stephen Frost 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 wrong?
:)
psql_du_
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 compare
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"
Ooops, sorry.
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, IIRC,
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 it.
* 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.
Ooops, sorry., One mistake:-(
Please this.
- Original Message -
From: "Hiroshi Saito"
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
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
securit
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 clone
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
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 lea
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 fr
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', 'someprivi
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, obviou
On 1/31/09, Marko Kreen wrote:
> On 1/31/09, Magnus Hagander wrote:
> > Hiroshi Saito wrote:
> > > Hi.
> > >
> > >>> dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o
> > >>> Warning: resolving _DllUnregisterServer by linking to
> > >>> _dllunregisterser...@0
> > >>> Us
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 ma
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. F
On Jan 31, 2009, at 2:44 PM, Heikki Linnakangas > 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 the old_shitty_widget
type. Then you j
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
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 and
On 1/31/09, Magnus Hagander 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
> >
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? Supp
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
throug
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
potent
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 addres
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_bat&dt=2009-01-31%2016:28:16
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hacker
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
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.
--
Dav
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 TO
phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser;
--
Sent via pgsql-hackers mailin
On 31 Jan 2009, at 17:17, Gregory Stark wrote:
Grzegorz Jaskiewicz 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
wo
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 http://fetter.org/
Phone: +1 415 235 3778 AI
Grzegorz Jaskiewicz 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 it an UNRESERVED
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:
http://www.post
> 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
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 a
>> 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 attr
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
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 tha
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
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 DB
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
detai
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? Cou
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 i
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 d
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
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
>>>
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 linki
Robert Haas wrote:
On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost 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 code.g
>>> 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 s
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.
On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost 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 code.googl
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 pg
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
>
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 ear
On Sat, Jan 31, 2009 at 4:21 AM, Simon Riggs 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 expand a row we
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 and
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 assigne
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 bg
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'
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 cra
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
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 syste
62 matches
Mail list logo
