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 postg
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 def
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 im
-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 befo
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
capaci
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
> t
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
> >
-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 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
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
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
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_Meetin
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 t
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 co
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 allow
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 thi
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 ...
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 av
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 poi
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 variab
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 relation
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 whol
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
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
tak
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 ide
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
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 d
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
b
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 ab
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 <[EMAI
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) 32
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 al
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 ju
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 Francis
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
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
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 th
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.
> >>
"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 abo
> 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 p
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 wo
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
"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
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
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.
rega
"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)
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 i
-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 c
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 scri
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 sub
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
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 h
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 brow
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 Post
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.
The
55 matches
Mail list logo
