Greg Smith wrote:
On Wed, 11 Jun 2008, Andrew Dunstan wrote:
If we want to help people to sponsor features, then I think we need
to deal with subjects like finding someone to undertake the
development, the sponsor's relationship with the developer, methods
and times of payment, etc.
Hm. Someone had his second finger chainsawed? Where is 8.3.2?
The ftp browser also shows 8.3.1 and 8.3.3, and 8.3.1 is the latest on
the main page.
Rawhide írta:
postgresql-8.3.3-1.fc10
---
* Wed Jun 11 18:00:00 2008 Tom Lane [EMAIL PROTECTED] 8.3.3-1
- Update to
8.3.2 was pulled back because of an urgent bugfix, and re-released as
8.3.3 since it had already hit the mirrors.
8.3.3 has not been officially releasde yet, but it will be out soon.
//Magnus
Zoltan Boszormenyi wrote:
Hm. Someone had his second finger chainsawed? Where is 8.3.2?
The ftp
Thanks for the info.
Magnus Hagander írta:
8.3.2 was pulled back because of an urgent bugfix, and re-released as
8.3.3 since it had already hit the mirrors.
8.3.3 has not been officially releasde yet, but it will be out soon.
//Magnus
Zoltan Boszormenyi wrote:
Hm. Someone had his
Greg Smith wrote:
On Wed, 11 Jun 2008, Andrew Dunstan wrote:
If we want to help people to sponsor features, then I think we need to
deal with subjects like finding someone to undertake the development,
the sponsor's relationship with the developer, methods and times of
payment, etc.
Tom Lane wrote:
I think the reason for the current behavior is to allow \set QUIET in
.psqlrc to affect the printing of the banner. Are we prepared to
give that up?
I'm using that behavior!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Monday, 9. June 2008 schrieb Tom Lane:
So while tagging the upcoming releases, I got annoyed once again about
what a tedious, error-prone bit of donkeywork it is.
Could you explain what the problem is? Your script sounds
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Also, I'd actually assert that 10 seems to be perfectly adequate for
the majority of users. That is, the number of users where I've
recommended increasing d_s_t for the whole database is smaller than the
number where I don't, and of course
Is there anyway to bind a cursor with SCROLL and WITH HOLD at the
protocol level?
Or perhaps configuring it so after binding it?
I know you can use DECLARE, but I believe that this inhibits the
driver from being
able to select the transfer format for individual columns; it's all
binary or
Greg Sabino Mullane [EMAIL PROTECTED] writes:
The orders of magnitude speed up of certain queries when the d_s_t goes
above 98 is what spawned my original thread proposing a change to 100:
http://markmail.org/message/tun3a3juxlsyjbsw
That was a pretty special case (LIKE/regex estimation), and
James William Pye [EMAIL PROTECTED] writes:
Is there anyway to bind a cursor with SCROLL and WITH HOLD at the
protocol level?
No, and for at least the first of those I don't see the point,
since the protocol doesn't offer any behavior other than forward
fetch.
On Jun 12, 2008, at 10:08 AM, Tom Lane wrote:
James William Pye [EMAIL PROTECTED] writes:
Is there anyway to bind a cursor with SCROLL and WITH HOLD at the
protocol level?
No, and for at least the first of those I don't see the point,
since the protocol doesn't offer any behavior other than
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Also, I'd actually assert that 10 seems to be perfectly adequate for
the majority of users. That is, the number of users where I've
recommended increasing d_s_t for the whole database is smaller than the
number where I don't, and of course we
Bruce,
I am concerned that each wizzard is going to have to duplicate the same
logic each time, and adjust to release-based changes.
I think that's a feature, not a bug. Right now, I'm not at all convinced that
my algorithms for setting the various major dials are great (I just think
that
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
4) Implementation
The main point of implementation is to have several version of
PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct
structure will be handled in special branch (see examples).
(this won't come as
Assuming that the threshold
for switching to an indexscan is somewhere around selectivity 0.005
(I am not certain offhand, but it's in that general area), this cannot
possibly require more than 200 MCV slots, and for most data
distributions it'd be a whole lot less.
Thats a really good
Nathan Boley [EMAIL PROTECTED] writes:
Given that, wouldn't it be smarter to consider a value as an mcv
candidate iff it has a density greater than 0.005, rather than having
a count greater than 1.5*average?
Yeah, perhaps ... want to experiment with that? Though I'd be a bit
worried about how
Andrew Dunstan wrote:
I need to use query like:
select (insert into test (a) values (x) returning b),c from anytable
where condition
but it say
ERROR: syntax error at or near into
Is this a bug?
No, it's a known limitation.
Is there a TODO item for this?
On Wed, 2008-06-11 at 19:24 -0400, Bruce Momjian wrote:
Is this desirable? \set QUIET at the top of .psqlrc fixes it, but I am
wondering if we should be automatically doing quiet while .psqlrc is
processed.
There is some precedent for not emitting the messages: most Unix tools
don't echo the
Neil Conway wrote:
On Wed, 2008-06-11 at 19:24 -0400, Bruce Momjian wrote:
Is this desirable? \set QUIET at the top of .psqlrc fixes it, but I am
wondering if we should be automatically doing quiet while .psqlrc is
processed.
There is some precedent for not emitting the messages: most
Josh Berkus wrote:
Bruce,
I am concerned that each wizard is going to have to duplicate the same
logic each time, and adjust to release-based changes.
I think that's a feature, not a bug. Right now, I'm not at all convinced
that
my algorithms for setting the various major dials are
Bruce,
I am thinking a web-based wizard would make the most sense.
I'd prefer command-line, so that people could run it on their own servers.
For one thing, we need to generate at least two files on many platforms; a
postgresql.conf and a sysctl.
--
Josh Berkus
PostgreSQL @ Sun
San
Josh Berkus wrote:
Bruce,
I am thinking a web-based wizard would make the most sense.
I'd prefer command-line, so that people could run it on their own servers.
For one thing, we need to generate at least two files on many platforms; a
postgresql.conf and a sysctl.
They can just
On Jun 12, 2008, at 11:21 AM, Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
I am concerned that each wizard is going to have to duplicate the
same
logic each time, and adjust to release-based changes.
I think that's a feature, not a bug. Right now, I'm not at all
convinced that
my
Hi all,
There is a TODO Item to allow pg_hba.conf to specify host names along
with IP addresses.
I'd like to work on this feature, if nobody is working too and no
objection exists.
Thanks.
--
[]s
Dickson S. Guedes
-
Projeto Colmeia - Curitiba - PR
+55 (41)
Dickson S. Guedes wrote:
Hi all,
There is a TODO Item to allow pg_hba.conf to specify host names along
with IP addresses.
I'd like to work on this feature, if nobody is working too and no
objection exists.
Please do --- I know of no one working on that.
--
Bruce Momjian [EMAIL
On Thu, 12 Jun 2008, Bruce Momjian wrote:
I am thinking a web-based wizard would make the most sense.
I have not a single customer I work with who could use an external
web-based wizard. Way too many companies have privacy policy restrictions
that nobody dare cross by giving out any info
looking in my freshly installed 8.3.3, I see this in the postgresql.conf
#client_encoding = sql_ascii# actually, defaults to database
# encoding
Now, certainly initdb can't know for sure what encoding a future database will
On Jun 12, 2008, at 8:49 AM, Alvaro Herrera wrote:
Greg Smith wrote:
On Wed, 11 Jun 2008, Andrew Dunstan wrote:
If we want to help people to sponsor features, then I think we
need to
deal with subjects like finding someone to undertake the
development,
the sponsor's relationship with the
Robert Treat [EMAIL PROTECTED] writes:
looking in my freshly installed 8.3.3, I see this in the postgresql.conf
#client_encoding = sql_ascii# actually, defaults to database
# encoding
Now, certainly initdb can't know for
On Jun 11, 2008, at 10:42 AM, Heikki Linnakangas wrote:
Another issue is that it might not be possible to update a page for
lack of space. Are we prepared to assume that there will never be a
transformation we need to apply that makes the data bigger?
We do need some solution to that. One
Tom Lane wrote:
Another issue is that it might not be possible to update a page for
lack of space. Are we prepared to assume that there will never be a
transformation we need to apply that makes the data bigger? In such a
situation an in-place update might be impossible, and that certainly
I require base64 or some similar encoding scheme from a C language
extension and need it to be as fast as reasonably possible. In
src/backend/utils/adt/encode.c there are functions b64_encode and
b64_decode which would be ideal but these are defined static and so are
not available to my code.
I
Decibel! wrote:
So were there decisions in the dev meeting about how the community wants
to handle people wanting to sponsor a project? Do they donate to SPI? Do
we have an escrow fund? Do we just point them at one of the Postgres
Companies and hope they're willing to pay for the whole
Decibel! wrote:
On Jun 12, 2008, at 8:49 AM, Alvaro Herrera wrote:
Greg Smith wrote:
On Wed, 11 Jun 2008, Andrew Dunstan wrote:
If we want to help people to sponsor features, then I think we need to
deal with subjects like finding someone to undertake the development,
the sponsor's
On Jun 11, 2008, at 9:34 PM, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The idea has a fundamental logical flaw, which is that it's not
clear
which parameter wins if the user changes both.
Yes, you could get into problems by having
James William Pye [EMAIL PROTECTED] writes:
On Jun 12, 2008, at 10:08 AM, Tom Lane wrote:
James William Pye [EMAIL PROTECTED] writes:
Is there anyway to bind a cursor with SCROLL and WITH HOLD at the
protocol level?
No, and for at least the first of those I don't see the point,
since the
Marc Munro wrote:
I require base64 or some similar encoding scheme from a C language
extension and need it to be as fast as reasonably possible. In
src/backend/utils/adt/encode.c there are functions b64_encode and
b64_decode which would be ideal but these are defined static and so are
not
Marc Munro [EMAIL PROTECTED] writes:
So, would there be any chance of redefining the base64 functions in
encode.c as extern to eliminate this redundancy?
It'd only last until the next time Bruce runs his script that
static-izes things that aren't used outside their own module ...
Decibel! [EMAIL PROTECTED] writes:
On Jun 11, 2008, at 9:34 PM, Bruce Momjian wrote:
I am kind of lost how this would work logically and am willing to
think
about it some more, but I do think we aren't going to simplify
postgresql.conf without such a facility.
Agreed. And I think it's a
On Thu, 12 Jun 2008, Alvaro Herrera wrote:
Incidentally, we have minutes from the meeting. Is it OK to publish
them openly?
There's a set of minutes already up at
http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting
There was no solution proposed to the escrow problem, nor to
On Thu, 2008-06-12 at 19:07 -0400, Andrew Dunstan wrote:
Marc Munro wrote:
I require base64 or some similar encoding scheme from a C language. . .
I know I could call these functions indirectly by calling binary_ecncode
through DirectFunctionCalln() but this is a whole lot more complexity
On Thu, 2008-06-12 at 19:10 -0400, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
So, would there be any chance of redefining the base64 functions in
encode.c as extern to eliminate this redundancy?
It'd only last until the next time Bruce runs his script that
static-izes things
On Thu, 2008-06-12 at 19:27 -0400, Greg Smith wrote:
On Thu, 12 Jun 2008, Alvaro Herrera wrote:
Incidentally, we have minutes from the meeting. Is it OK to publish
them openly?
There's a set of minutes already up at
http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting
On Jun 12, 2008, at 3:59 PM, Tom Lane wrote:
Sure, but if you're willing to use a SQL-level operation on the portal
then you could perfectly well declare the cursor at SQL level too.
Indeed, but like I said in my initial e-mail::
I know you can use DECLARE, but I believe that this inhibits
Marc Munro [EMAIL PROTECTED] writes:
On Thu, 2008-06-12 at 19:10 -0400, Tom Lane wrote:
It'd only last until the next time Bruce runs his script that
static-izes things that aren't used outside their own module ...
Hmmm. Does that script look in contrib? If so I'd be happy to provide
a
James William Pye [EMAIL PROTECTED] writes:
Indeed, but like I said in my initial e-mail::
I know you can use DECLARE, but I believe that this inhibits the
driver from being able to select the transfer format for individual
columns; it's all binary or it's all text.
Huh? I don't
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
That was a pretty special case (LIKE/regex estimation), and we've since
eliminated the threshold change in the LIKE/regex estimates anyway, so
there's no longer any reason to pick 100 as opposed to any other number.
So we're still back at
On Thursday 12 June 2008 17:38:26 Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
looking in my freshly installed 8.3.3, I see this in the postgresql.conf
#client_encoding = sql_ascii# actually, defaults to database
Robert Treat [EMAIL PROTECTED] writes:
looking in my freshly installed 8.3.3, I see this in the postgresql.conf
#client_encoding = sql_ascii# actually, defaults to database
# encoding
But isn't putting a default that is likely to be wrong just encouraging
people
to set it to
On Jun 12, 2008, at 4:45 PM, Tom Lane wrote:
Huh? I don't see why... you might have such a limitation in a
particular driver, but not in the protocol.
Oh? I know when you bind a prepared statement you have the ability
state the formats of each column, but I'm not aware of the protocol's
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Really? I'm the opposite: I never leave a client's setting at 10, that's
just asking for trouble. Making it 100 *after* you encounter problem
queries is reactive; I prefer being proactive.
Have you ever measured the system speed before and
You guys call this simplification? You're out of your minds.
This proposal is ridiculously complicated, and yet it still fails
even to consider adjusting non-numeric parameters. And what about
things that require more than a trivial arithmetic expression to
compute? It's not hard at all to
On Thursday 12 June 2008 21:11:57 Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
looking in my freshly installed 8.3.3, I see this in the
postgresql.conf #client_encoding = sql_ascii# actually,
defaults to database # encoding
But isn't putting a default that is
Robert Treat wrote:
This conversation is beginning to suggest to me that client_encoding
shouldn't be listed in postgresql.conf at all.
Yeah, that sure seems better than what we currently have.
I should have thought there was a good argument for preventing its being
set in
55 matches
Mail list logo
