Am Mittwoch, den 19.10.2005, 22:04 +0200 schrieb Tino Wildenhain:
> Am Mittwoch, den 19.10.2005, 16:29 -0300 schrieb Marc G. Fournier:
> > I'm CC'ng this over to -hackers ... Tom? Comments?
> >
> ...
> > >> Then we are broken too :)
> > >>
> > >> # select 'a ' = 'a ';
> > >> ?column?
> > >> -
Tom Lane <[EMAIL PROTECTED]> writes:
> Chris Travers <[EMAIL PROTECTED]> writes:
> > If I understand the spec correctly, it seems to indicate that this is
> > specific to the locale/character set.
>
> The spec associates padding behavior with collations, which per spec are
> separate from the da
Chris Travers <[EMAIL PROTECTED]> writes:
> If I understand the spec correctly, it seems to indicate that this is
> specific to the locale/character set.
The spec associates padding behavior with collations, which per spec are
separate from the datatypes --- that is, you should be able to able to
Lyubomir Rusanov wrote:
> Hi,
> I am also interested in helping building Bulgarian translation for
> PostgreSQL.
> I think that we will not have enough time for 8.1 but maybe for 8.2.
The best you could do is submit your incremental improvements for 8.1,
so there is at least _some_ translation.
Josh Berkus wrote:
Dann,
I think that whatever is done ought to be whatever the standard says.
If I misinterpret the standard and PostgreSQL is doing it right, then
that is fine. It is just that PostgreSQL is very counter-intuitive
compared to other database systems that I have used in thi
Hello,
Some of you may have noted the new project I am playing with the
PostgreSQL Source browser.
It is a Subversion->Trac interface to the PostgreSQL CVS repository. The
entire repository
is represented. It is currently updated daily but I am hoping to get
this down to hourly in
the near fu
If there is a significant performance benefit to not expanding text columns in
comparison operations, then it seems it should be OK.
I probably read the standard wrong, but it seems to me that varchar, char, and
bpchar columns should all behave the same (e.g. if you do not expand with
or the P
Dann,
> I think that whatever is done ought to be whatever the standard says.
> If I misinterpret the standard and PostgreSQL is doing it right, then
> that is fine. It is just that PostgreSQL is very counter-intuitive
> compared to other database systems that I have used in this one
> particular
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 19, 2005 2:46 PM
> To: Dann Corbit
> Cc: Terry Fielder; Tino Wildenhain; Marc G. Fournier;
> [EMAIL PROTECTED]; pgsql-hackers@postgresql.org; pgsql-
> [EMAIL PROTECTED]
> Subject: Re: 'a
> -Original Message-
> From: Stephan Szabo [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 19, 2005 2:34 PM
> To: Dann Corbit
> Cc: Terry Fielder; Tino Wildenhain; Marc G. Fournier;
> [EMAIL PROTECTED]; pgsql-hackers@postgresql.org; pgsql-
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] '
On Wed, Oct 19, 2005 at 02:05:20PM -0700, Dann Corbit wrote:
> > When the compared datatypes are VARCHAR: YES
>
> What is the value of doing that?
>
> I can see plenty of harm and absolutely no return. We are talking about
> blank padding before comparison. Do you really want 'Danniel '
> consi
On Wed, 19 Oct 2005, Dann Corbit wrote:
> > -Original Message-
> > From: Terry Fielder [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, October 19, 2005 2:05 PM
> > To: Dann Corbit
> > Cc: Tino Wildenhain; Marc G. Fournier; [EMAIL PROTECTED];
> > pgsql-hackers@postgresql.org; pgsql-general@p
> -Original Message-
> From: Terry Fielder [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 19, 2005 2:05 PM
> To: Dann Corbit
> Cc: Tino Wildenhain; Marc G. Fournier; [EMAIL PROTECTED];
> pgsql-hackers@postgresql.org; pgsql-general@postgresql.org
> Subject: Re: 'a' == 'a ' (Was: RE: [p
"Guy Rouillier" <[EMAIL PROTECTED]> writes:
> Tino Wildenhain wrote:
> >
> > experiment=# SELECT 'a '::char = 'a '::char;
> > ?column?
> > --
> > t
> >
>
> This does't show anything useful, because the ::char casting simply
> takes the first char of any string:
>
> select 'abc'::char
Try this query in Oracle, SQL*Server, DB/2, Informix, etc.:
connxdatasync=# select 1 where cast('a' as varchar(30)) = cast('a ' as
varchar(30));
?column?
--
(0 rows)
I see how you can interpret the SQL Standard to make the above response
a correct one. But is it the response that you wo
Am Mittwoch, den 19.10.2005, 16:29 -0300 schrieb Marc G. Fournier:
> I'm CC'ng this over to -hackers ... Tom? Comments?
>
> On Wed, 19 Oct 2005, Dann Corbit wrote:
>
> > Yes, clearly that is the wrong result according to the SQL standard.
> >
> > Here is a SQL*Server query:
> > select 1 where 'a
Kevin,
> This would require capture of information beyond what I was thinking
> about in terms of schema. Do you think we need to capture just index
> type, or something more? Do you propose that we capture the pg_*
> metadata related to every object referenced in the plan, every object
> relate
Given this part of that same rule applied to the strings:
"b) If the length in characters of X is not equal to the length in
characters of Y, then the shorter string is effectively replaced, for
the purposes of comparison, with a copy of itself that has been extended
to the length of the longer str
On Wed, 19 Oct 2005, Dann Corbit wrote:
-Original Message-
From: Stephan Szabo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 19, 2005 12:39 PM
To: Dann Corbit
Cc: Marc G. Fournier; [EMAIL PROTECTED]; pgsql-
[EMAIL PROTECTED]
Subject: Re: [pgsql-advocacy] [GENERAL] Oracle buys Innoba
This would require capture of information beyond what I was thinking
about in terms of schema. Do you think we need to capture just index
type, or something more? Do you propose that we capture the pg_*
metadata related to every object referenced in the plan, every object
related to every table i
I'm CC'ng this over to -hackers ... Tom? Comments?
On Wed, 19 Oct 2005, Dann Corbit wrote:
Yes, clearly that is the wrong result according to the SQL standard.
Here is a SQL*Server query:
select 1 where 'a' = 'a ' AND 'a' = 'a ' AND 'a ' = 'a '
It returns (correctly): 1
-Orig
Robert Treat wrote:
On Tuesday 18 October 2005 18:05, Kevin Grittner wrote:
Regarding the idea of a site where results could be posted
and loaded into a database which would be available for
public access -- I agree that would be great; however, my
client is not willing to take that on. I
Maybe we could associate a set of defaults to runtime_environment,
and you would associate any overrides with the runtime_options.
Does this address both your concerns?
>>> Josh Berkus >>>
Kevin,
> When it gets downt to the detail, it may make sense to combine
> or split some of these. For ex
On Tuesday 18 October 2005 18:05, Kevin Grittner wrote:
> Regarding the idea of a site where results could be posted
> and loaded into a database which would be available for
> public access -- I agree that would be great; however, my
> client is not willing to take that on. If anyone wants to
> v
I'm not interested in storing less information. I'm trying to make sure
that all redundant information is justified. Since I plan to store the
actual query text and the full EXPLAIN ANALYZE output, every
column I pull out and put in another table is redundant data. The
questions are, why do we h
Kevin,
> When it gets downt to the detail, it may make sense to combine
> or split some of these. For example, runtime_options should
> probably not have a column for each currently known option,
> but a child table which maps to all non-default option values.
I'm a little cautious about storing
Summary of schema I'm considering. Comments welcome.
When it gets downt to the detail, it may make sense to combine
or split some of these. For example, runtime_options should
probably not have a column for each currently known option,
but a child table which maps to all non-default option value
Hi,
On Tue, 18 Oct 2005, Tony Caduto wrote:
I installed 8.04 via RPM on Centos 4.2 which is the same as RedHat 4.2 and
while booting the init script reports that the daemon [FAILED], but after I
logon it shows the postmaster running and I am able to connect from any
client remotely.
I made
Kevin,
> If we stored the actual queries and the EXPLAIN ANALYZE results (when
> generated) in the database, what would be the purpose of the node_name,
> db_object, and condition_detail columns? They don't seem like they
> would be useful for statistical analysis, and it seems like the
> informa
If we stored the actual queries and the EXPLAIN ANALYZE results (when
generated) in the database, what would be the purpose of the node_name,
db_object, and condition_detail columns? They don't seem like they
would be useful for statistical analysis, and it seems like the
information would be more
http://lca2005.linux.org.au/Papers/Neil%20Conway/Inside%20the%20PostgreSQL%20Query%20Optimizer/pg_query_optimizer.pdf
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Sebastián Ávila
> Sent: Wednesday, October 19, 2005 9:04 AM
> To: pgs
see src/backend/optimizer/README
On 10/19/05, Sebastián Ávila <[EMAIL PROTECTED]> wrote:
Hi people,Please I need help about this, where I could find information aboutthe query optimization system in postgresql?Thanks!---(end of broadcast)---
TIP 5: do
Hi people,
Please I need help about this, where I could find information about
the query optimization system in postgresql?
Thanks!
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
daveg wrote:
Apologies if this is old news, but pg_autovacuum in 8.0.x has the bad habit
of SEGVing and exiting when a table gets dropped out from under it. This
creates problems if you rely on pg_autovacuum for the bulk of your vacuuming
as it forgets it's statistics when it is restarted and so
Hi,
I am also interested in helping building Bulgarian translation for
PostgreSQL.
I think that we will not have enough time for 8.1 but maybe for 8.2.
Regards
Lyubomir Rusanov
Ivan Pavlov wrote:
Peter Eisentraut wrote:
As the release of PostgreSQL 8.1 draws near, it is once aga
Martijn van Oosterhout wrote:
> On Tue, Oct 18, 2005 at 10:07:26PM -0500, Larry Rosenman wrote:
>>> ...or attach with a debugger like gdb.
>>
>> d'oh. I go stupid occasionally :)
>>
>> If someone wants me to, I can try that.
>
> Yes, actually. See, its dying in the seg test already with:
>
>
On Wed, Oct 19, 2005 at 04:24:21AM -0700, Kevin Brown wrote:
> It does? It looked to me like it was setting the signal handler to
> SIG_IGN before doing the popen(), and resetting it to the internal
> signal handler after doing the pclose().
Oops, you're right. It works because less sets it's own
Peter Eisentraut wrote:
> As the release of PostgreSQL 8.1 draws near, it is once again time to update
> the translations of the program messages. To check the status of your
> language, check out this web site:
>
> http://developer.postgresql.org/~petere/nlsstatus/
>
> To participate in t
On 2005-10-19, Kevin Brown <[EMAIL PROTECTED]> wrote:
> Making assumptions about what the pager will do upon receipt of SIGINT
> is folly as well.
>
> Setting up SIGINT to be ignored may be the right answer (I don't
> believe it is -- see below), but if so then it needs to be done
> properly. If i
On 2005-10-19, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> Suppose I have a database with a table in it. I try to dump that
> database. The user I dump as is not the owner of that table nor does it
> have the SELECT permission on that table.
>
> Why can't I do a schema-only dump of tha
Martijn van Oosterhout wrote:
> On Tue, Oct 18, 2005 at 09:32:25PM -0700, Kevin Brown wrote:
> > So I think the right answer here is for psql to handle SIGINT
> > internally by doing a pclose() first (and at this point, it probably
> > should ignore SIGINT altogether), then returning to the main lo
Hi All,
At system crash or poweroff the autovacuum statistics will be lost,
because this statistics only stored in RAM and saved/restored at
service shutdown/startup.
I think it should be saved periodically and not to be deleted after
crash.
On Tue, Oct 18, 2005 at 10:07:26PM -0500, Larry Rosenman wrote:
> >...or attach with a debugger like gdb.
>
> d'oh. I go stupid occasionally :)
>
> If someone wants me to, I can try that.
Yes, actually. See, its dying in the seg test already with:
-- Open intervals
SELECT '0..'::seg AS seg
On Tue, Oct 18, 2005 at 09:32:25PM -0700, Kevin Brown wrote:
> So I think the right answer here is for psql to handle SIGINT
> internally by doing a pclose() first (and at this point, it probably
> should ignore SIGINT altogether), then returning to the main loop
> (and, of course, cleaning up anyt
Apologies if this is old news, but pg_autovacuum in 8.0.x has the bad habit
of SEGVing and exiting when a table gets dropped out from under it. This
creates problems if you rely on pg_autovacuum for the bulk of your vacuuming
as it forgets it's statistics when it is restarted and so will skip some
Suppose I have a database with a table in it. I try to dump that
database. The user I dump as is not the owner of that table nor does it
have the SELECT permission on that table.
Why can't I do a schema-only dump of that table? I find that I need
SELECT permission on the table, even though
Anand Kumria wrote:
Hi,
I have a set of perl scripts which invoke each other (via system());
eventually I found that they were crashing and ultimately causing Perl
to SIGSEGV.
I am using Debian testing and have recompiled postgres-8.0.3-15 to
include debugging symbols. This is a dual-CPU dual-
47 matches
Mail list logo
