On Tue, Jul 08, 2008 at 07:28:36AM +0200, Hans-Juergen Schoenig wrote:
good morning everybody,
i know that this is really a hot potato on the mailing list but i
think it is useful to discuss this issue. in the past few months
we have been working with a customer to improve evgen's CONNECT
On Thu, 2008-07-03 at 16:36 +0200, Bernd Helmle wrote:
--On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian [EMAIL PROTECTED]
wrote:
I'd like to implement them if we agree on them
Bernd, have you made any progress on this?
Here's a patch for this. I'll add it to the commit fest
On Mon, Jul 07, 2008 at 12:06:08PM -0700, David E. Wheeler wrote:
I guess that'd be the reason to keep it on pgFoundry, but I have two
comments:
* 2-3 years is a *long* time in Internet time.
There have been patches over the years, but they tend not to get looked
at. Recently someone
Martijn van Oosterhout napsal(a):
On Mon, Jul 07, 2008 at 12:06:08PM -0700, David E. Wheeler wrote:
I guess that'd be the reason to keep it on pgFoundry, but I have two
comments:
* 2-3 years is a *long* time in Internet time.
There have been patches over the years, but they tend not to get
On Mon, Jul 7, 2008 at 6:36 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Dave Page wrote:
it concerns me that despite it being day 3 of the July commit fest,
people are still being advised to add new items to the wiki page.
To make the idea work, we need to stick to the rules we defined when
we
Tom Lane napsal(a):
Gregory Stark [EMAIL PROTECTED] writes:
Out of curiosity, what is a user-defined collation? Are there SQL statements
to go around declaring what order code points should be sorted in? That seems
like it would be... quite tedious!
snip
We might be best off to treat
Here is the patches he made against CVS HEAD (as of today).
According to him followings are fixed with the patches:
- fix crush with DISTINCT
- fix creating VIEW
- fix the case when recursion plan has another recursion plan under it
- fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong
KaiGai Kohei wrote:
Might want to change the option name --enable-selinux to something
like --security-context.
In general, we might want to not name things selinux_* but instead
sepostgresql_* or security_* or security_context_*. Or maybe PGACE?
The pgace_* scheme is an attractive idea,
On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
I mentioned that I planned to remove SELECT/CONNECT too.
Now I've thought about it more and it seems to me that its better
to keep them. As they give additional flexibility.
I very much like PL/Proxy and support your vision. Including
Zdenek Kotala napsal(a):
I though more about it and I discussed it with Radek yesterday. The
problem is that collation must be created before user want to use CREATE
DATABASE ... COLLATE ... command. It inclines to have have pg_collation
as a global catalog, but ANSI specifies to use schema
On Tue, Jul 08, 2008 at 11:27:35AM +0200, Zdenek Kotala wrote:
Zdenek Kotala napsal(a):
I though more about it and I discussed it with Radek yesterday. The
problem is that collation must be created before user want to use CREATE
DATABASE ... COLLATE ... command. It inclines to have have
Martijn van Oosterhout napsal(a):
On Tue, Jul 08, 2008 at 11:27:35AM +0200, Zdenek Kotala wrote:
Zdenek Kotala napsal(a):
I though more about it and I discussed it with Radek yesterday. The
problem is that collation must be created before user want to use CREATE
DATABASE ... COLLATE ...
On Tue, Jul 08, 2008 at 12:00:34PM +0200, Zdenek Kotala wrote:
Not necessarily. pg_class is not shared yet without it you can't even
find pg_database. Same deal with pg_type. All it means is that
pg_collation in template1 must contain all the collations used in
template1, which shouldn't be
Martijn van Oosterhout napsal(a):
Oh I see, you're referring to the storage of the default collation for
a database. I was jumping ahead to the per-column collation state, when
the collation default is attached to columns, types and domains, and
not at the database level. So there the problem
On Mon, 2008-07-07 at 10:51 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-07-07 at 11:03 +0900, ITAGAKI Takahiro wrote:
One issue is tag field. The type is now uint32. It's enough in my plugin,
but if some people need to add more complex structures in
On Jul 7, 2008, at 7:39 PM, Tom Lane wrote:
Another point to keep in mind, if you are trying to analyze files
belonging to a live database, is that what you can see in the
filesystem
may not be the current contents of every page. For typical access
patterns it'd be unsurprising for the
On Mon, 2008-07-07 at 11:03 -0700, Josh Berkus wrote:
Brendan,
What I'm saying is, I've got the opportunity and the inclination to
make the wiki more usable. If you guys want better navigation,
there's a suggestion on the table to improve that. I'm not too
worried about the wiki
Simon Riggs wrote:
On Mon, 2008-07-07 at 16:26 -0700, David Fetter wrote:
On Mon, Jul 07, 2008 at 06:46:29PM -0400, Andrew Dunstan wrote:
For the record, I agree with Jan's suggestion of passing a pointer
to the parse tree, and offline gave David a suggestion verbally as
to how this
Jaime Casanova escribió:
On Thu, May 22, 2008 at 1:18 PM, Jaime Casanova [EMAIL PROTECTED] wrote:
Hi,
The idea of this patch is to avoid the need to make explicit grants on
sequences owned by tables.
I've noted that the patch i attached is an older version that doesn't
compile because
Zdenek Kotala [EMAIL PROTECTED] writes:
Martijn van Oosterhout napsal(a):
Not necessarily. pg_class is not shared yet without it you can't even
find pg_database. Same deal with pg_type. All it means is that
pg_collation in template1 must contain all the collations used in
template1, which
Simon Riggs [EMAIL PROTECTED] writes:
It would be very useful if people would add a comment like started my
review of X now. Otherwise people don't know whether the reviewer is
actually reviewing it at length, or just intend to at some point.
That's a good idea, imho, I'll try to do that
--
Zdenek Kotala [EMAIL PROTECTED] writes:
... And of course shared tables need also collation for their indexes.
No, they don't, because the only textual indexes on shared catalogs are
on name columns, which are intentionally not locale aware, and
wouldn't be collation aware either.
Simon Riggs wrote:
The notes say Heikki doesn't think this is a long term solution, but
in the following discussion it was the *only* way of doing this that
will work with non-PostgreSQL databases. So it seems like the way we
would want to go, yes?
How did you come to the conclusion that this
Tom Lane wrote:
All the argument here is based on the premise that we should have
database-level collation specifications, which AFAICS is not required
nor suggested by the SQL spec. I wonder why we are allowing a
nonstandard half-measure to drive our thinking, rather than solving the
real
On Tue, Jul 08, 2008 at 10:54:28AM -0400, Andrew Dunstan wrote:
Agreed. Are we even sure that we want per-database collations as a
half-way house? Unless we can be sure that we want all the required
catalog changes for the full requirement, it seems to me a rather messy
way of getting to
On Tue, 2008-07-08 at 17:51 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
The notes say Heikki doesn't think this is a long term solution, but
in the following discussion it was the *only* way of doing this that
will work with non-PostgreSQL databases. So it seems like the way we
Simon Riggs wrote:
SQL, in text form, is the interface to other databases. You can't pass
half a plan tree to Oracle, especially not a PostgreSQL plan tree. It
has to be text if you wish to send a query to another RDBMS, or another
version of PostgreSQL.
Oh, I see. Agreed.
Though note that
On Tue, 2008-07-08 at 10:21 +0100, Simon Riggs wrote:
On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
I very much like PL/Proxy and support your vision. Including the
features of PL/Proxy in core seems like a great idea to me.
Adding this feature for tables would be interesting with
On 7/8/08, Simon Riggs [EMAIL PROTECTED] wrote:
On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
I mentioned that I planned to remove SELECT/CONNECT too.
Now I've thought about it more and it seems to me that its better
to keep them. As they give additional flexibility.
I very
On Tue, Jul 08, 2008 at 06:22:23PM +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
SQL, in text form, is the interface to other databases. You can't
pass half a plan tree to Oracle, especially not a PostgreSQL plan
tree. It has to be text if you wish to send a query to another
RDBMS, or
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 2008-07-08 at 10:21 +0100, Simon Riggs wrote:
On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
I very much like PL/Proxy and support your vision. Including the
features of PL/Proxy in core seems like a great idea to me.
On Tue, 2008-07-08 at 18:29 +0300, Marko Kreen wrote:
and potentially SPREAD BY as discussed in:
http://lists.pgfoundry.org/pipermail/plproxy-users/2008-June/93.html
That *sounds* cool, but its just the first part of the implementation of
a massively parallel executor. You'll quickly
On Tue, 2008-07-08 at 18:43 +0300, Marko Kreen wrote:
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
First let me say that I too enjoy PL/Proxy quite a bit. However, I don't
think it needs to be in core. I wouldn't mind seeing it in contrib (or
better yet modules/ should we ever
On Tue, 2008-07-08 at 08:58 -0700, Joshua D. Drake wrote:
On Tue, 2008-07-08 at 18:43 +0300, Marko Kreen wrote:
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
First let me say that I too enjoy PL/Proxy quite a bit. However, I don't
think it needs to be in core. I wouldn't mind
On 7/8/08, Alvaro Herrera [EMAIL PROTECTED] wrote:
Jaime Casanova escribió:
On Thu, May 22, 2008 at 1:18 PM, Jaime Casanova [EMAIL PROTECTED] wrote:
Hi,
The idea of this patch is to avoid the need to make explicit grants on
sequences owned by tables.
I've noted that the patch i
On 7/8/08, Simon Riggs [EMAIL PROTECTED] wrote:
On Tue, 2008-07-08 at 18:29 +0300, Marko Kreen wrote:
and potentially SPREAD BY as discussed in:
http://lists.pgfoundry.org/pipermail/plproxy-users/2008-June/93.html
That *sounds* cool, but its just the first part of the
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 2008-07-08 at 18:43 +0300, Marko Kreen wrote:
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
First let me say that I too enjoy PL/Proxy quite a bit. However, I don't
think it needs to be in core. I wouldn't mind seeing
Andrew, Tom,
Agreed. Are we even sure that we want per-database collations as a
half-way house? Unless we can be sure that we want all the required
catalog changes for the full requirement, it seems to me a rather messy
way of getting to where we want to go.
Given that we don't have a
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Martijn van Oosterhout napsal(a):
Not necessarily. pg_class is not shared yet without it you can't
even
find pg_database. Same deal with pg_type. All it means is that
pg_collation in template1 must contain all the collations used in
Tom,
Indeed. If the Solaris folk feel that getupeercred() is insecure,
they had better explain why their kernel is that broken. This is
entirely unrelated to the known shortcomings of the ident IP
protocol.
The Solaris security kernel folks do, actually. However, there's no
question
All,
The pgace_* scheme is an attractive idea, although the server process
has to provide a bit more hints (like the name of security system column
and the kind of objects exported with security attribute) pg_dump to
support various kind of security features with smallest implementation.
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
... And of course shared tables need also collation for their indexes.
No, they don't, because the only textual indexes on shared catalogs are
on name columns, which are intentionally not locale aware, and
wouldn't be collation aware
I have had some idle thoughts on the issue of identifier case folding. Maybe
we can collect our ideas and inch closer to a solution sometime. Or we
determine that it's useless and impossible, but then I can at least collect
that result in the wiki and point future users to it.
Background:
Josh Berkus wrote:
Tom,
Indeed. If the Solaris folk feel that getupeercred() is insecure,
they had better explain why their kernel is that broken. This is
entirely unrelated to the known shortcomings of the ident IP
protocol.
The Solaris security kernel folks do, actually.
On Tue, 2008-07-08 at 19:25 +0200, Peter Eisentraut wrote:
4. Compare the name data type in a case-insensitive manner. This
would probably address most problem cases. Again, you can't have
objects with names
different in case only. One condition to implementing this would be
that this
Peter Eisentraut [EMAIL PROTECTED] writes:
I have had some idle thoughts on the issue of identifier case folding.
...
Comments?
IMHO, practically the only solid argument for changing from the way
we do things now is to meet the letter of the spec. The various sorts
of gamesmanship you list
Josh Berkus [EMAIL PROTECTED] writes:
Andrew, Tom,
Agreed. Are we even sure that we want per-database collations as a
half-way house? Unless we can be sure that we want all the required
catalog changes for the full requirement, it seems to me a rather messy
way of getting to where we want to
Am Dienstag, 8. Juli 2008 schrieb Tom Lane:
IMHO, practically the only solid argument for changing from the way
we do things now is to meet the letter of the spec.
Well no. As I have mentioned, there have actually been occasional complaints
by people who can't run their code generated by
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Dienstag, 8. Juli 2008 schrieb Tom Lane:
IMHO, practically the only solid argument for changing from the way
we do things now is to meet the letter of the spec.
Well no. As I have mentioned, there have actually been occasional complaints
by
On 7/8/2008 11:38 AM, David Fetter wrote:
On Tue, Jul 08, 2008 at 06:22:23PM +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
SQL, in text form, is the interface to other databases. You can't
pass half a plan tree to Oracle, especially not a PostgreSQL plan
tree. It has to be text if you
I looked this over and it looks good in general.
May I think that patch passed review and commit it?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list
Teodor Sigaev [EMAIL PROTECTED] writes:
I looked this over and it looks good in general.
May I think that patch passed review and commit it?
I'd still like to take a look.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Martijn van Oosterhout napsal(a):
Not necessarily. pg_class is not shared yet without it you can't even
find pg_database. Same deal with pg_type. All it means is that
pg_collation in template1 must contain all the collations used in
Josh Berkus wrote:
Tom,
Indeed. If the Solaris folk feel that getupeercred() is insecure,
they had better explain why their kernel is that broken. This is
entirely unrelated to the known shortcomings of the ident IP
protocol.
The Solaris security kernel folks do, actually. However,
Andrew Dunstan napsal(a):
Tom Lane wrote:
All the argument here is based on the premise that we should have
database-level collation specifications, which AFAICS is not required
nor suggested by the SQL spec. I wonder why we are allowing a
nonstandard half-measure to drive our thinking,
Tom,
IMHO, practically the only solid argument for changing from the way
we do things now is to meet the letter of the spec. The various sorts
of gamesmanship you list would most definitely not meet the letter of
the spec; between that and the inevitability of breaking some apps,
I'm
On Tuesday 08 July 2008 23:04:51 Josh Berkus wrote:
Tom,
IMHO, practically the only solid argument for changing from the way
we do things now is to meet the letter of the spec. The various sorts
of gamesmanship you list would most definitely not meet the letter of
the spec; between
Josh Berkus [EMAIL PROTECTED] wrote:
Actually, there are a number of *very* popular database tools,
particularly
in the Java world (such as Netbeans and BIRT) which do mix quoted and
unquoted identifiers. In general, users of those tools reject
PostgreSQL
as broken for our nonstandard
Tom Lane wrote:
What I think would perhaps be worth investigating is a compile-time
(or at latest initdb-time) option that flips the case folding behavior
to SQL-spec-compliant and also changes all the built-in catalog entries
to upper case. We would then have a solution we could offer to
Ron Mayer [EMAIL PROTECTED] wrote:
+1 for a compile-time option for spec-compliant behavior. Even
where the spec is stupid (timestamp with time zone literals) it'd
be nice to have the option; both for feature completeness
checklists and for teachers who want to teach targeting the spec.
Kevin Grittner [EMAIL PROTECTED] writes:
Josh Berkus [EMAIL PROTECTED] wrote:
Actually, there are a number of *very* popular database tools,
particularly
in the Java world (such as Netbeans and BIRT) which do mix quoted and
unquoted identifiers.
Do these tools expect an unquoted identifier
Jan Urbański wrote:
If you think the Lossy Counting method has potential, I could test it
somehow. Using my current work I could extract a stream of lexemes as
ANALYZE sees it and run it through a python implementation of the
algorithm to see if the result makes sense.
I hacked together a
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
Right. From a user's perspective 4) sounds best. I often run into problems
having keywords as column-names:
None of the proposals on the table will remove the need to use quotes in
that case.
regards, tom lane
--
Sent
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
Do you think it's worthwhile to implement the LC algorithm in C and send
it out, so others could try it out? Heck, maybe it's worthwhile to
replace the current compute_minimal_stats() algorithm with LC and see
how that compares?
In trying to port postgres to 64-bit Windows, I've encountered a
number of issues which may (or may not) affect other compilers. If
you followed the other thread, this is mostly a summary with a bit
more details so feel free to ignore it. Some of these may have some
minor effects on other
Peter Eisentraut wrote:
I have had some idle thoughts on the issue of identifier case folding. Maybe
we can collect our ideas and inch closer to a solution sometime. Or we
determine that it's useless and impossible, but then I can at least collect
that result in the wiki and point future
Peter Eisentraut [EMAIL PROTECTED] writes:
One disadvantage is that one could no longer have objects that have names
different only by case, but that is probably rare and incredibly stupid and
can be neglected.
Certainly not if you hope to claim being within a mile of spec -- which seems
like
Andrew Dunstan wrote:
I'm not sure if you've read all the archive history on this. Here are
the pointers from the TODO list:
http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php
http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
Here is the patches he made against CVS HEAD (as of today).
The git repository should now match this :)
http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary
Apparently, it's easiest to clone via the following URL:
David Fetter wrote:
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
Here is the patches he made against CVS HEAD (as of today).
The git repository should now match this :)
http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary
Apparently, it's easiest to
70 matches
Mail list logo
