On Mon, 2007-04-23 at 17:48 -0400, Tom Lane wrote:
I think we've got something isomorphic to that in the patch queue
already --- take a look at Pavel's table function patch. It's in
need of cleanup but I think it will make it in.
Interesting -- I missed that patch, but it seems like a better
Hello
It is RETURN TABLE(SQL) via ANSI SQL 2003
Table function support is in patch queue:
http://archives.postgresql.org/pgsql-patches/2007-02/msg00216.php
http://momjian.us/mhonarc/patches/msg1.html
Regards
Pavel Stehule
In a PL/PgSQL set-returning function, returning the result set
Neil Conway [EMAIL PROTECTED] writes:
Interesting -- I missed that patch, but it seems like a better approach.
Are you already reviewing Pavel's patch, or is it something I could take
a look at?
The main objection I have is that I don't think changing the definition
of pg_proc.proargmodes is a
On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
Our first attempt to use the ECPG prepare interface revealed that ECPG
doesn't use the PQlib prepare function. The ECPG prepare replaces any
parameters with their values and presents a new SQL statement to the
This is true and
3) To maintain crash recovery chance and reduce the amount of
archive log, removal of unnecessary full page writes from
archive logs is a good choice.
Definitely, yes. pg_compresslog could even move the full pages written
during backup out of WAL and put them in a different file that needs
A few of us on IRC were wondering what the status of tsearch2 is in 8.3 ?
Was it decided to include it in core or did we decide to keep FTS as a
plugin?
Some brief comments from anyone on the inside of the whole FTS issue
would be greatly appreciated by us mere end users.
Regards,
- Naz.
On 4/23/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Oh, you're talking about distributing partitions across different nodes
and parallelizing queries. No, we don't do that today.
PL/Proxy actually works like that, only in smaller scope -
for function calls only.
General solution that
Heikki Linnakangas wrote:
Tom Lane wrote:
Also, we have a generic issue that making fresh entries in a hashtable
might result in a concurrent hash_seq_search scan visiting existing
entries more than once; that's definitely not something any of the
existing callers are thinking about.
Ouch.
Hi all,
I'm one of the Google SoC's students for PostgreSQL. My project is
to implement column-level privilege in PG. Here is a description of my
project. Any and all help and/or comment is appreciated.
Table-level privilege subsystem in PG is now used like this:
GRANT { { SELECT | INSERT |
On Tuesday 24 April 2007 01:32, Magnus Hagander wrote:
That would be just because you don't know the numbering scheme. 8.2 to
8.3 is considered major in these parts. See
http://www.postgresql.org/support/versioning
Is that official policy? I don't see any mention of it in the docs.
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
The main data from the statistics that's of interest here are the extreme
values of the histogram. If we're not interested in any values in that range
then we can exclude the partition entirely.
Except that there is
On Tue, Apr 24, 2007 at 09:18:54AM -0400, Robert Treat wrote:
On Tuesday 24 April 2007 01:32, Magnus Hagander wrote:
That would be just because you don't know the numbering scheme. 8.2 to
8.3 is considered major in these parts. See
http://www.postgresql.org/support/versioning
Michael Meskes wrote:
On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
Our first attempt to use the ECPG prepare interface revealed that ECPG
doesn't use the PQlib prepare function. The ECPG prepare replaces any
parameters with their values and presents a new SQL statement
Magnus Hagander wrote:
On Tue, Apr 24, 2007 at 09:18:54AM -0400, Robert Treat wrote:
On Tuesday 24 April 2007 01:32, Magnus Hagander wrote:
That would be just because you don't know the numbering scheme. 8.2 to
8.3 is considered major in these parts. See
I want to apologize for having my signature at the bottom of the 8.2.4,
etc. release announcement. There is no reason to mention my name,
company, and web site at the bottom of something that is supposed to
come from the community. And I didn't even write that email --- I was
doing it for
Bruce Momjian wrote:
I want to apologize for having my signature at the bottom of the 8.2.4,
etc. release announcement. There is no reason to mention my name,
company, and web site at the bottom of something that is supposed to
come from the community. And I didn't even write that email --- I
Naz Gassiep wrote:
A few of us on IRC were wondering what the status of tsearch2 is in 8.3 ?
Was it decided to include it in core or did we decide to keep FTS as a
plugin?
Some brief comments from anyone on the inside of the whole FTS issue
would be greatly appreciated by us mere end users.
On 4/23/07, Neil Conway [EMAIL PROTECTED] wrote:
On Tue, 2007-04-17 at 16:34 +0300, Marko Kreen wrote:
Attached patch does following conversions:
ISTM it would be cleaner to use an enum to identify the different
variants of the DISCARD command, rather than a character string.
Is guc.c still
Heikki Linnakangas [EMAIL PROTECTED] writes:
I briefly went through all callers of hash_seq_init. The only place
where we explicitly rely on being able to add entries to a hash table
while scanning it is in tbm_lossify. There's more complex loops in
portalmem.c and relcache.c, which I think
In the modified version of ECPG that we used for our benchmark, we
PREPARE'd all statements.
-Original Message-
From: Michael Meskes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 12:45 AM
To: William Lawrance
Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Golden Liu wrote:
3. Before evaluating a SQL command, check column-level privilege.
This is done AFTER checking table-level privilege. As I mentioned
before, if table-level privilege is granted, it's not necessary to
check column-level privilege.
Golden, this sounds good. I'm just a user.
It
The resolution to my problem with the select_common_type() error message
turned out to be that this doesn't work:
postgres=# select null union select null union select 1;
ERROR: UNION types text and integer cannot be matched
That's because it resolves the first two branches independently, then
Am Dienstag, 24. April 2007 14:54 schrieb Golden Liu:
Here is a plan of my project:
All of that should be pretty straightforward. But have you given any thoughts
to how you want to represent the column privileges in the parse tree and how
you want to process them in the rewriter? That will
Peter Eisentraut [EMAIL PROTECTED] writes:
The resolution to my problem with the select_common_type() error message
turned out to be that this doesn't work:
postgres=# select null union select null union select 1;
ERROR: UNION types text and integer cannot be matched
Yeah, this has been
Tom Lane [EMAIL PROTECTED] writes:
Maybe we should just ignore those qualms and do it anyway --- I must
admit that I'm hard-pressed to come up with a situation where anyone
would really want different datatypes used in the inner union than
the outer.
Does it even matter except in the case of
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Maybe we should just ignore those qualms and do it anyway --- I must
admit that I'm hard-pressed to come up with a situation where anyone
would really want different datatypes used in the inner union than
the outer.
Koichi, Andreas,
1) To deal with partial/inconsisitent write to the data file at crash
recovery, we need full page writes at the first modification to pages
after each checkpoint. It consumes much of WAL space.
We need to find a way around this someday. Other DBs don't do this; it may be
Josh Berkus [EMAIL PROTECTED] writes:
Well, as a PG hacker I find the name wal_fullpage_optimization quite
baffling and I think our general user base will find it even more so.
Now that I have Koichi's explanation of the problem, I vote for simply
slaving this to the PITR settings and not
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Does it even matter except in the case of nulls? I mean, if the inner pair
uses integer and then the outer pair uses bigint it'll still work correctly,
no?
Oh, it absolutely matters: you can get different answers.
Am Dienstag, 24. April 2007 19:48 schrieb Tom Lane:
You're missing the point, which is that the inner UNION needs to decide
what its uniqueness semantics are, independently of what might happen to
its result later. Or that's how I read the spec anyway.
It's probably safer to leave it as is.
On Tue, 2007-04-24 at 07:58 +0200, Pavel Stehule wrote:
It is RETURN TABLE(SQL) via ANSI SQL 2003
I think there are two basically orthogonal features in the patch: the
RETURNS TABLE addition to CREATE FUNCTION, and the RETURN TABLE
statement in PL/PgSQL. The former is specified by the SQL
Bruce, All,
(x-posting to Advocacy, hopefully to forestall flames)
I want to apologize for having my signature at the bottom of the 8.2.4,
etc. release announcement. There is no reason to mention my name,
company, and web site at the bottom of something that is supposed to
come from the
Josh Berkus wrote:
Bruce, All,
(x-posting to Advocacy, hopefully to forestall flames)
I want to apologize for having my signature at the bottom of the 8.2.4,
etc. release announcement. There is no reason to mention my name,
company, and web site at the bottom of something that is
Tom Lane wrote:
The pending-fsync stuff in md.c is also expecting to be able to add
entries during a scan.
No, mdsync starts the scan from scratch after calling AbsorbFsyncRequests.
I don't think we can go in the direction of forbidding insertions during
a scan --- as the case at hand shows,
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
The pending-fsync stuff in md.c is also expecting to be able to add
entries during a scan.
No, mdsync starts the scan from scratch after calling AbsorbFsyncRequests.
That was last month ;-). It doesn't restart any more.
We could
[ CC'ing -hackers ]
On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote:
This patch adds a sentence on monitoring.sgml explaining that
stats_row_level needs to be enabled if user wants to get last
vacuum/analyze execution time.
This behavior was introduced in r1.120 of
On Tue, 24 Apr 2007, Ned T. Crigler wrote:
The JDBC driver does not connect successfully to a CVS HEAD server
(updated as of today) when using a database set to UTF8 encoding;
enabling the debug messages in the driver shows that it is sending
client_encoding=UNICODE in the startup packet, but
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of August Zajonc
Sent: dinsdag 24 april 2007 18:34
To: Golden Liu
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Google SoC: column-level privilege subsystem
Golden Liu wrote:
3. Before evaluating a
It sounds like table || column is the check, so table implies
all of columns. ie, revoking a column permission does nothing
unless TABLE permission is also revoked.
IF this will be implemented as suggested here, it will become
extremely
counter-intuitive. Its just like you have access to
On Tuesday 24 April 2007 17:38, Neil Conway wrote:
[ CC'ing -hackers ]
On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote:
This patch adds a sentence on monitoring.sgml explaining that
stats_row_level needs to be enabled if user wants to get last
vacuum/analyze execution time.
Dear August
Thank you for your reply.
On 4/25/07, August Zajonc [EMAIL PROTECTED] wrote:
Golden Liu wrote:
3. Before evaluating a SQL command, check column-level privilege.
This is done AFTER checking table-level privilege. As I mentioned
before, if table-level privilege is granted, it's
Robert Haas wrote:
My strongly opinion is that, REVOKE column-level priviledge should
revoke access to that column, in effect it should reduce the table-level
grant to column-level grants.
I think this causes problems when columns are added to the table. If
table X has columns A, B, C,
two of my buildfarm members had different but pretty weird looking
failures lately:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quaggadt=2007-04-25%2002:03:03
and
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emudt=2007-04-24%2014:35:02
any ideas on what might causing those ?
I think there are two basically orthogonal features in the patch: the
RETURNS TABLE addition to CREATE FUNCTION, and the RETURN TABLE
statement in PL/PgSQL. The former is specified by the SQL standard and
is applicable to all PLs, while the latter is syntax sugar for PL/PgSQL.
I think it would
Kris Jurka [EMAIL PROTECTED] writes:
On Tue, 24 Apr 2007, Ned T. Crigler wrote:
The JDBC driver does not connect successfully to a CVS HEAD server
(updated as of today) when using a database set to UTF8 encoding;
Indeed, referring to -hackers as this is a recent backend change. The
backend
Robert Haas [EMAIL PROTECTED] writes:
...
IF this will be implemented as suggested here, it will become
extremely counter-intuitive.
...
You could solve this by having explicit positive and negative ACLs, i.e.
your permissions for a particular column are:
Uh, wait a moment, people. The
Tom Lane wrote:
Robert Haas [EMAIL PROTECTED] writes:
...
IF this will be implemented as suggested here, it will become
extremely counter-intuitive.
...
You could solve this by having explicit positive and negative ACLs, i.e.
your permissions for a particular column are:
47 matches
Mail list logo
