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 ba
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 thin
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.
> > > >
> > >
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.
> >
> > regar
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
=?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 obses
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 s
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 th
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 reas
"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 l
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?
Ag
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 tr
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; [EM
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 pgsql-h
[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
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
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:
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 har
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
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
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.
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 reje
-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 sh
"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*
>> thi
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.
cursors_tuple_fracti
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 c
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 thin
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("COMMI
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 s
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
>
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 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.
W
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 i
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 th
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
> wi
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 w
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 & instead. Has this somehow
been HTML entity-ified?
Hi Brendan,
You are ri
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
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 this
39 matches
Mail list logo
