Tom Lane napsal(a):
I wrote:
Another possible answer is to change the minimum to be just 64K always.
I'm not certain that it's really sensible to tie the minimum work_mem to
BLCKSZ --- I don't think we do anything where work_mem is controlling a
pool of page buffers, do we?
I've committed
Am Samstag, 26. April 2008 schrieb Euler Taveira de Oliveira:
One of the few parts of the core that is not localized is the ecpg.
Attached is a patch that builds the basic infrastructure to make it
possible. Besides that I worked on some strings to make them conform
with [1] but I didn't do
Dickson dos Santos Guedes wrote:
On Sat, Apr 12, 2008 at 7:43 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
I was going to try this patch out, but it would not apply. Seems that
where the patch should have , it has amp; instead. Has this somehow
been HTML entity-ified?
Hi Brendan,
You are
This is a little complex to explain - so its probably better with an example..
I don't know if theres some inbuilt function to tell you what datatype a value
is - so 'kludged' this together :
CREATE OR REPLACE FUNCTION rval_type(m date) RETURNS text AS $$
BEGIN
RETURN 'it
On Thu, May 01, 2008 at 09:58:09PM -0400, Andrew Chernow wrote:
The more I think about it, I personally like the display behavior of NTFS
file times over something like EXT3. When I am in EDT, it is useful to
have all display times in that zone (regardless of whether that time falls
Andrew Sullivan wrote:
On Thu, May 01, 2008 at 09:58:09PM -0400, Andrew Chernow wrote:
The more I think about it, I personally like the display behavior of NTFS
file times over something like EXT3. When I am in EDT, it is useful to
have all display times in that zone (regardless of whether
**Andrew Sullivan wrote:
On Thu, May 01, 2008 at 06:33:07PM +0200, PFC wrote:
But it's true that preventing multi-statements adds a layer of
idiot-proofness... a rather thin layer...
As I already said in a previous remark in this thread, I don't really
like partial security solutions.
On Fri, May 02, 2008 at 09:54:20AM -0400, Andrew Chernow wrote:
I prefer offset from UTC, the timezone abbrevs are ambiguos and confusing.
So did you read the manual on SET TIME ZONE?
TIME ZONE
SET TIME ZONE value is an alias for SET timezone TO value. The
syntax SET TIME ZONE
Andrew Chernow wrote:
I prefer offset from UTC, the timezone abbrevs are ambiguos and
confusing. If I am in a timezone that is currently 4 hours behind
UTC, I would prefer all times to display adjusted by that offset. I
understand that technically its eastern time and EDT makes no sense
Andrew Dunstan [EMAIL PROTECTED] writes:
This fix is surely wrong for several reasons:
. the configure changes only broke MSVC builds, not all Windows builds
(see narwhal, for example), but this change applies to both.
. fixing a change that adds a configure option by hardcoding it in
Darren Reed [EMAIL PROTECTED] writes:
Also, I think the no-multistatement SQL should default to on.
Not happening, for backwards-compatibility reasons.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Darren Reed wrote:
Because interacting with the database is always through an action
that you do and if you're being half way intelligent about it, you
are always checking that each action succeeded before going on to
the next.
Hmm, it won't be pretty for the drivers that do PQexec(COMMIT;
On Fri, May 02, 2008 at 02:28:31PM +0100, Mike Aubury wrote:
Any thoughts ?
As I already explained in private email ecpg uses an untyped statement
and data is always send as text. Of course this could be changed but
only by looking into the backend and asking what datatype this is. I
don't
On Thu, 2008-04-03 at 16:45 +0200, Hell, Robert wrote:
This patch adds a GUC parameter for tuple_fraction of cursors (discussed
earlier here:
http://archives.postgresql.org/pgsql-performance/2008-04/msg00018.php).
By setting this parameter the planner's favor to use fast-start plans
for
Simon Riggs wrote:
* We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
Don't want hints. If that's what we really think, then this patch must
surely be rejected because its a hint... That isn't my view. I *now*
think we do need hints of various kinds.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Simon Riggs wrote:
* We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
Don't want hints. If that's what we really think, then this patch must
surely be rejected because its a hint... That isn't my view. I *now*
think we do need
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Hmm, it won't be pretty for the drivers that do PQexec(COMMIT; BEGIN).
The driver will think that it's in a transaction when in fact the second
command in the string has been ignored, and so it's not ...
Any driver that is doing that should
On Fri, 2008-05-02 at 12:01 -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Simon Riggs wrote:
* We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
Don't want hints. If that's what we really think, then this patch must
surely be rejected because its
On Fri, 2008-05-02 at 16:17 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
* We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
Don't want hints. If that's what we really think, then this patch must
surely be rejected because its a hint... That isn't my view. I *now*
On Fri, 2008-05-02 at 12:01 -0400, Tom Lane wrote:
I see this as being basically another cost parameter, and as such
I don't think it needs more documentation than any of those have.
(Now admittedly you could argue that they could all use a ton more
documentation than they now have, but it's
On Fri, May 2, 2008 at 7:16 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Although it would often be nice to see tables sorted by size, I don't like
having a different ordering in verbose mode, that's just confusing.
Yes, I agree.
Patch committed, sans the ordering change. I also moved the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
This fix is surely wrong for several reasons:
. the configure changes only broke MSVC builds, not all Windows builds
(see narwhal, for example), but this change applies to both.
. fixing a change that adds a configure option by
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, maybe the right answer is to take a step back and figure out what
pg_config.h.win32's excuse for living is at all.
Oops, the file is only used by MSVC/BCC, not by MinGW. Sorry for the
mistake about that.
Well, I'm still
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, maybe the right answer is to take a step back and figure out what
pg_config.h.win32's excuse for living is at all.
Oops, the file is only used by MSVC/BCC, not by MinGW. Sorry for the
mistake
[EMAIL PROTECTED] (Alvaro Herrera) writes:
Darren Reed wrote:
Because interacting with the database is always through an action
that you do and if you're being half way intelligent about it, you
are always checking that each action succeeded before going on to
the next.
Hmm, it won't be
Simon Riggs [EMAIL PROTECTED] writes:
OK, if that's the view then the patch is ready for commit, AFAICS.
Use of the plural in the name seems a bit odd to me. Anyone have a
problem with calling it cursor_tuple_fraction instead?
regards, tom lane
--
Sent via
You're right - that's just a typo in the subject of the post.
It's called cursor_tuple_fraction in the submitted patch.
Regards,
Robert
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Freitag, 02. Mai 2008 22:36
To: Simon Riggs
Cc: Heikki Linnakangas; Hell, Robert;
On Fri, May 02, 2008 at 03:58:01PM -0400, Chris Browne wrote:
Andrew Sullivan recently had some choice words about the merits of
ENUM; I think the same applies to drivers that do
PQexec(COMMIT;BEGIN)...
Oh, heaven. I can at least think of ways to use ENUM such that you
can justify the
On Fri, 2008-05-02 at 16:36 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
OK, if that's the view then the patch is ready for commit, AFAICS.
Use of the plural in the name seems a bit odd to me. Anyone have a
problem with calling it cursor_tuple_fraction instead?
Agreed.
--
Hell, Robert [EMAIL PROTECTED] writes:
You're right - that's just a typo in the subject of the post.
It's called cursor_tuple_fraction in the submitted patch.
Ah, I hadn't actually read the patch yet ;-). As penance for the noise,
I will do so now.
regards, tom lane
While looking around vacuum.h (for my GSoC project) I found:
typedef struct VacAttrStats *VacAttrStatsP;
and then throughout the code sometimes VacAttrStats *foo is used and
sometimes VacAttrStatsP bar is used.
Call this obsessive-compulsive disorder, but it kind of bothers me. Is
there a
Andrew Sullivan [EMAIL PROTECTED] writes:
Oh, heaven. I can at least think of ways to use ENUM such that you
can justify the trade-off. I can think of no excuse whatever for
PQexec(COMMIT; BEGIN). That's just lazy and sloppy.
Note also that more recent releases, concurrent with the
On Fri, 2008-05-02 at 23:22 +0200, Jan Urbański wrote:
While looking around vacuum.h (for my GSoC project) I found:
typedef struct VacAttrStats *VacAttrStatsP;
and then throughout the code sometimes VacAttrStats *foo is used and
sometimes VacAttrStatsP bar is used.
Personally I think we
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
While looking around vacuum.h (for my GSoC project) I found:
typedef struct VacAttrStats *VacAttrStatsP;
and then throughout the code sometimes VacAttrStats *foo is used and
sometimes VacAttrStatsP bar is used.
Call this
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Samstag, 26. April 2008 schrieb Euler Taveira de Oliveira:
One of the few parts of the core that is not localized is the ecpg.
Attached is a patch that builds the basic infrastructure to make it
possible.
Looks good for a start, but what is
Bryce Nesbitt wrote:
Tom Lane wrote:
Well, personally I haven't read the core code yet, since it's not commit
fest yet ;-). I don't know whether there are any issues there, but it
wouldn't surprise me given the number of issues in the control code.
regards, tom
Bruce Momjian wrote:
Peter Eisentraut wrote:
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
Peter Eisentraut wrote:
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
We do look at COLUMNS if the ioctl() fails, but not for file/pipe
output.
This is quite a useless
OK, so COLUMNS should take precedence. I assume this is going to
require us to read the COLUMNS enviroment variable in psql _before_
readline sets it, and that COLUMNS will only affect screen output, like
ioctl(). Is that consistent?
This whole thing is confusing enough at the point, I
Peter Eisentraut wrote:
Looks good for a start, but what is missing in this patch is that mmerror and
the other functions actually call gettext. So currently this patch doesn't
achieve a lot.
I don't know if I understand what you want to say by call gettext. A
quick look at the l10n of
39 matches
Mail list logo
