The newline handling code was, by far, the most complex part of this
patch. While I think it would be nicer to filter up past the newline,
I just don't see this as a common need. Large text fields with newlines
are difficult to really view in psql anyway, and they are likely to be
the
1) \pset columns XX should make it clear that's for file output only.
2) There's an extra space, which breaks \pset border 2
717c717
fputc(' ', fout);;
---
fputc(' ', fout);
842c842
Tom Lane [EMAIL PROTECTED] writes:
BTW, I trolled the contrib files for other v0 functions taking or
returning float4 or float8. I found seg_size (fixed it) and a whole
bunch of functions in earthdistance. Those use float8 not float4,
so they are not broken by this patch, but that module
Gregory Stark írta:
Tom Lane [EMAIL PROTECTED] writes:
BTW, I trolled the contrib files for other v0 functions taking or
returning float4 or float8. I found seg_size (fixed it) and a whole
bunch of functions in earthdistance. Those use float8 not float4,
so they are not broken by this
Gregory Stark [EMAIL PROTECTED] writes:
So are you killing V0 for non-integral types? Because if not we should keep
some sacrificial module to the regression tests to use to test for this
problem.
Well, we could potentially continue to have, say, the oldstyle
geo_distance function used when
Alvaro Herrera wrote:
The developer's FAQ is supposed to contain this kind of thing, but I
think it's rather thin on actual details. (Some time ago it was
proposed to create a style guide, but people here thought it was a
waste of time and it will not cover what's really important, so we're
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
I tried to split the previous patch up to see where the tsearch regression
comes from. So, it turned out that:
- float4 conversion is risk free (patch #1)
- float8 conversion is okay, too, if coupled with time[stamp[tz]] conversion
(patch #2)
Gregory Stark [EMAIL PROTECTED] writes:
4) Your problems with tsearch and timestamp etc raise an interesting problem.
We don't need to mark this in pg_control because it's a purely a run-time
issue and doesn't affect on-disk storage.
Just for the record, that's wrong. It's true that
On Mon, Apr 21, 2008 at 2:28 AM, Tom Lane [EMAIL PROTECTED] wrote:
Applied with revisions --- mostly, supporting configure-time control
over whether pass-by-value is used.
Do we need buildfarm coverage of these options?
--
Guillaume
--
Sent via pgsql-patches mailing list
Guillaume Smet [EMAIL PROTECTED] writes:
On Mon, Apr 21, 2008 at 2:28 AM, Tom Lane [EMAIL PROTECTED] wrote:
Applied with revisions --- mostly, supporting configure-time control
over whether pass-by-value is used.
Do we need buildfarm coverage of these options?
Wouldn't hurt, I guess, though
10 matches
Mail list logo
