Marc, care to do the honors?
---
Peter Eisentraut wrote:
> Simon Riggs wrote:
> > On Thu, 2008-09-11 at 15:39 +0300, Peter Eisentraut wrote:
> >> Bruce Momjian wrote:
> >>> Abhijit Menon-Sen wr
Peter Eisentraut wrote:
> Simon Riggs wrote:
> > On Thu, 2008-09-11 at 15:39 +0300, Peter Eisentraut wrote:
> >> Bruce Momjian wrote:
> >>> Abhijit Menon-Sen wrote:
> >>>> I thought -patches was supposed to die. What happened?
> >>> I was w
ur subscription:
> http://www.postgresql.org/mailpref/pgsql-patches
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql
Abhijit Menon-Sen wrote:
> I thought -patches was supposed to die. What happened?
I was wondering the same thing. Peter?
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard driv
s well i can add them, too.
>
> --
> Thanks
>
> Bernd
[ Attachment, skipping... ]
>
> --
> Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-patch
>> retval foo%ROWTYPE;
> > >> >>
> > >> >>
> > >> >> Currently the OUT parameters are quite painful to use due to bad
> > >> >> name resolving logic. Such feature would be perfect replacement.
> > >> >
retval foo%ROWTYPE;
> >> >>
> >> >>
> >> >> Currently the OUT parameters are quite painful to use due to bad
> >> >> name resolving logic. Such feature would be perfect replacement.
> >> >>
> >> >&g
hould we set this to PGC_SUSET like
> > all the other logging functions?
>
> Patch enclosed.
Patch applied, docs updated.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your
g list (pgsql-patches@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-patches
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a
ucred()
> > because they have some other way to do it). You need an explicit
> > configure probe for the header file too, I think.
> Ok, I can fix that.
Garick, have you made any progress on an updated patch?
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.u
y "%p" /mnt/server/archivedir/"%f"' # Windows
> +archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows
>
>
>
>
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software C
py "%p" "C:\\server\\archivedir\\%f"' # Windows
>
>
>
>
>
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
>
> --
> Sent via pgsql-patches mailing list (pgsql-patches@postgresql.
> array_fill
> ---
> {NULL,NULL,NULL,NULL}
> (1 row)
>
> Regards
> Pavel Stehule
[ Attachment, skipping... ]
>
> --
> Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
> To make changes to your subscription:
> http
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Update patch applied; I also adjusted some translation function calls.
> > The new output of psql \d+ is:
> >
> > test=> \d+ test
> > Table "public.test"
> >
--+-+-----
x | integer | | plain |
Has OIDs: no
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterpri
cs also has the advantage of being more available,
> searchable, and found via the web.
Agreed, applied.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be
t, but the docs do seem updated.
Done:
* Fix TRUNCATE ... RESTART IDENTITY so its affect on sequences is rolled
back on transaction abort
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a
; raised issue and in an area of code that will be superceded in the next
> release.
>
> So further embellishments would be a long way down my own priority list,
> putting it politely. Yet I have no objections to the suggestion overall;
> we have done that already for alter ta
the attached, applied patch.
Thanks for the observation. (The patch also removes a duplicate
definition of parse_version().)
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ
Cliff Nieuwenhuis wrote:
> On Fri, 9 May 2008 08:38:01 -0400
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > Bruce Momjian escribi?:
> > > Guillaume Smet wrote:
> > > > On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian <[EMAIL PROTECTED]>
> >
> Anybody mind if I update that to put more emphasis on the need for
> documentation? As in "documentation patches are *required* if
> your patch adds or changes user-visible behavior"?
Sure, but I do documentation updates for non-English speakers
occasionally.
--
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> I've always assumed that I'm supposed to backpatch the bugs I fix in
> >> HEAD, however far is reasonable.
>
> > I thought we only backatched major bugs t
to start using
only the hackers list. This will require email server changes and web
site updates, and some people who are only subscribed to patches have to
figure out if they want to subscribe to hackers.
I have CC'ed hackers, patches, and www because this does affect all
those lists.
Added to July patch queue. Thanks.
---
Simon Riggs wrote:
> Re-sending post as discussed with Bruce...
>
> On Sun, 2008-03-23 at 12:45 -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > &
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > Why do we need someone to complain? We know the bug is there. Has the
> > > code changed a lot in that area?
> >
> > Do we have the policy of backpatching every fix? I
Bruce Momjian wrote:
> I am attaching a minimal patch that will fix the bug in back branches.
> Keep in mind that a patched pg_ctl will not be able to restart a backend
> that was not patched.
I think this patch will work for unpatched backends as well. I am still
uncertain if it
Bruce Momjian wrote:
> > > > > "", meaning zero-length string. I should have seen the bug when I
> > > > > applied the contributed patch in 2004.
> > > >
> > > > So, shouldn't this fix be back-patched?
> > >
> >
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > However, as of 2004-10-15, this has not worked. :-( The attached patch
> > > > is the one that caused the bug --- on non-Unix
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > However, as of 2004-10-15, this has not worked. :-( The attached patch
> > is the one that caused the bug --- on non-Unix systems, SYSTEMQUOTE is
> > "", meaning zero-length string. I should hav
in 2004.
The second attached applied patch fixes the problem.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backe
the pg_ctl -o option, the file still necessary so
> > that
> > you get the same options after a restart.
>
> No, it's the "postmaster.opts.default" file that I'm complaining about,
> not the postmaster.opts file.
The attached applied patch remove
Joshua D. Drake wrote:
> Alex Hunsaker wrote:
> > On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >> I would like to get do this without adding a new --use-statement-timeout
> >> flag. Is anyone going to want to honor statement_timeo
Alex Hunsaker wrote:
> On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > I would like to get do this without adding a new --use-statement-timeout
> > flag. Is anyone going to want to honor statement_timeout during
> > pg_dump/pg_restore? I
daveg wrote:
> On Mon, Jun 23, 2008 at 06:51:28PM -0400, Bruce Momjian wrote:
> > Alex Hunsaker wrote:
> > > On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera
> > > <[EMAIL PROTECTED]> wrote:
> > > > Joshua D. Drake escribi?:
> > > &
command line
> option --use-statement-timeout) for pg_dump and pg_restore.
I would like to get do this without adding a new --use-statement-timeout
flag. Is anyone going to want to honor statement_timeout during
pg_dump/pg_restore? I thought we were just going to disable it.
--
Bruce
ems.
>
> I'm not sure about the command names - there was already a tendency in
> the recent discussion to mix the notion of installation of code on the
> filesystem versus installation into a particular user's database. The
> convention for doing stuff i
itcap and wcs* code to another file. pg_locale.c?
> BTW, formatting.c and oracle_compat.c already include pg_locale.h.
I researched this idea but is seems pg_locale.c contains only
locale-specific stuff, while these functions have locale and non-locale
versions; I ended up moving the common
Bruce Momjian wrote:
> > I am starting to think that the simplest case is to keep the single-copy
> > version in there for single-byte encodings and not worry about the
> > overhead of the multi-byte case.
>
> My new idea is if we pass the length to str_initcap, we can eli
Bruce Momjian wrote:
> > Actually it seems like the hard part is not so much the input
> > representation as the output representation --- what should the
> > base-level initcap routine return, to be reasonably efficient for
> > both cases?
>
> I hadn't gotten
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I'd say not. Can't we do some more refactoring and avoid so many
> >> useless conversions? Seems like str_initcap is the wrong primitive API
> >> --- the w
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The third step is for oracle_compat.c::initcap() to use
> > formatting.c::str_initcap(). You can see the result; patch attached
> > (not applied).
>
> > This greatly reduces the size of initcap(
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > > I moved str_initcap() over into oracle_compat.c and then had initcap()
> > > > convert to/from TEXT to call it. The code is a little w
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > I moved str_initcap() over into oracle_compat.c and then had initcap()
> > > convert to/from TEXT to call it. The code is a little weird because
> > > str_initcap() needs to
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I moved str_initcap() over into oracle_compat.c and then had initcap()
> > convert to/from TEXT to call it. The code is a little weird because
> > str_initcap() needs to convert to text to use texttowcs(), so in
> &g
to text to use texttowcs(), so in
multibyte encodings initcap converts the string to text, then to char,
then to text to call texttowcs(). I didn't see a cleaner way to do
this.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB
ruce and you been
> backported to 8.3? I didn't see it on pgsql-commiters.
No. I have not backpatched it because Tom found a problem with my
applied patch and did a second patch.
I am attaching both patches. The second one is Tom's and I don't
understand it well enough t
Now that upper/lower/initcase do not modify the passed string, I have
simplified formatting.c with the attached patch.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Chri
four years:
>
> /*
> * for some reason MinGW (and MSVC) outputs an extra newline, so
> this
> * suppresses it
> */
> #ifndef WIN32
> fputc('\n', fout);
> #endif
>
> I have removed the kluge (and yes, I te
stgresql.org/message-id/[EMAIL PROTECTED]
---
Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > Euler, have you updated this patch yet?
> >
> Here is an updated patch. It follows the Oracle behaviour and uses a
> cache mechanism to avoid ca
t keeps stdout
but uses a different output stream. I am just unsure, given all the
features of psql, wether it could change stdin/stdout while running in
some way.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.co
bal.mk?r1=1.12&r2=1.13)
FYI, I had to also apply the attached patch to fix it, but your example
on the line above was very helpful.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is
Bruce Momjian wrote:
> OK, here is the mega-print:
>
> $ psql test
> psql (8.4devel, server 8.4devel)
> WARNING: psql version 8.4, server version 8.4.
>Some psql features might not work.
> WARNING: Console code page (44) differs from
Bruce Momjian wrote:
> The attached patch causes psql to use the pager if newlines or
> 'format=wrapped' has caused a single row to span more than one line and
> the output is then too long for the screen. It also uses the pager if
> psql thinks the data will wrap off
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> > > Magnus Hagander wrote:
> > > > Attached patch adds some error checking to the thread locking
> > > > stuff in libpq. Previously, if thread locking failed for some
> > >
option is used, none
of this happens. This is useful with the -c option.
Within psql you can also set the QUIET variable to
achieve the same effect.
You could then use \echo in .psqlrc to make your own banner.
--
Bruce Momjian <[EMAIL PROTECTED]
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > With major version mismatches it looks like this:
>
> > $ psql test
> > psql (8.4devel)
> > SSL connection (cipher: 2343, bits: 512)
> > WARNING: Console code
.1.
Some psql features might not work.
Type "help" for help.
test=>
By indenting those messages the 'help' message still stands out.
Adjustments?
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
Enterp
ate the default, but then anyone with their own .psqlrc
> can re-define it to whatever they think is a "good enough" UI.
We could do that but we still have to design the default banner.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oh, good point. Let me look at that. Thanks. You prefer:
>
> > $ sql test
> > psql (8.4devel)
> > Type "help" for help.
>
> > test=> help
>
> Wel
er throw it away and say,
> "Nice try JD" or just commit the thing.
Your patch is getting the same review any other patch would have. If
you want someone else to apply it I will stop working on it.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
Enterpr
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Ah, OK. I had forgotten. Here is the new output:
>
> > $ sql test
> > psql (8.4devel) Type "help" for help.
>
> > test=> help
>
> You are being unreaso
Joshua D. Drake wrote:
> Bruce Momjian wrote:
>
> >
> > test=> \?
> > General
> > \copyright show PostgreSQL usage and distribution terms
> > \g [FILE] or ; send query buffer to server (and results to file or
> > |pipe)
&
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Bruce Momjian wrote:
> >>
> >>> My question is whether we agreed that suggesting "help" as the best way
> >>> to get help was what we agreed upon? If we
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > My question is whether we agreed that suggesting "help" as the best way
> > to get help was what we agreed upon? If we did, I forgot. I thought
> > the 'help' ideas was just for people who forg
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I know we decided not to do that, but I am trying to figure out what the
> > goal if 'help' is? To display the most frequently-used help commands?
> > Aren't they at the top of \?.
>
> The purpos
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > If you type 'help' it just repeats the startup banner suggestion:
> >
> > test=> help
> >
> > You are using psql, the command-line interface to PostgreSQL.
> > Type \? for h
tch attached.
FYI, after the patch is applied I will update psql banner examples in
our documentation.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your ba
, but I think now it is clean enough to be used by new people
without confusion.
I also put the version number in parentheses so it wouldn't be as
prominent.
Updated patch attached.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB
ewhat imperfect.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/s
t is a
> major improvement over PQexecParams.
One idea would be to add the libpq hooks but not document them. This
way, we can modify or remove the API as needed in the future. As
libpqtypes matures and we are sure what the API should be, we can
document it as stable and permanent.
--
Bruc
ing them to libpq. The
complexity of the API just mirrors my gut feeling on this.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent vi
FirstOffsetNumber; offnum <= nline; offnum =
> OffsetNumberNext(offnum))
> {
> lp = PageGetItemId(page, offnum);
> Assert(ItemIdHasStorage(lp));
>
>
> --
> Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
> To make change
on of installation of code on the
> filesystem versus installation into a particular user's database. The
> convention for doing stuff in a db is CREATE/DROP, but CREATE MODULE
> doesn't feel right to me, just as I don't really like CREATE LANGUAGE.
> How about ENABLE/DISABLE
--
> Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-patches
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://en
There is also the comment:
* Increments/decrements the argument. These macros look pointless
* but they help us disambiguate the different manipulations on
* OffsetNumbers (e.g., sometimes we subtract one from an
* OffsetNumber to move back, and sometimes we do so to form a
*
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Guillaume Smet wrote:
> >> I understand your point of view but I really think it's more a
> >> regression fix than a behavior change.
>
> > If I can get other hackers to say we should b
Guillaume Smet wrote:
> On Fri, May 9, 2008 at 4:38 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > No, we don't change behaviors in back branches unless we get lots of
> > complaints, and we haven't in this case.
>
> I suspect it's annoying for a lo
Guillaume Smet wrote:
> On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Applied.
>
> As I mentioned it before, is there any chance for this fix to be
> backported to 8.3 branch? IMHO it's a usability regression.
No, we don&
Applied.
---
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > > I have
Applied.
---
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> >
> > > > Surely psql computes the width of all cells before printing an
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > Attached patch adds some error checking to the thread locking stuff in
> > libpq. Previously, if thread locking failed for some reason, we would
> > just fall through and do things without locking. This patch makes us
> >
exit(1); \
} while(0)
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-patches mailing list (pgsql-patche
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Ah, got it, and I updated the patch to remove the commment about
> > "discrete".
>
> The page also says that 0^x is undefined when x is negative, not sure
> about that one but I don't see it in
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > I have developed the attached patch which fixes 0 ^ 123.3.
> > >
> > > Did you actually read the wikipedia entry you cit
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have developed the attached patch which fixes 0 ^ 123.3.
>
> Did you actually read the wikipedia entry you cited?
Yes:
The evaluation of 0^0 presents a problem, because different mathematical
reasoning leads
> where your parameter is ignored a bit of a contortion. The part that
> > detects based on the database is after all the other parsing because the
> > connection has to be brought up first.
>
> Yeah. But couldn't we have that part issue a warning if -s had bee
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > Surely psql computes the width of all cells before printing anything.
> >
> > It does, but if you have a value that has a tab, how do you know what
> > tab stop you are on becaus
test=> select 0 ^ 0;
?column?
--
1
(1 row)
test=> select 0 ^ 0.0;
?column?
--
1
(1 row)
test=> select 0 ^ 3.4;
?column?
--
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > Surely psql computes the width of all cells before printing anything.
> >
> > It does, but if you have a value that has a tab, how do you know what
> > tab stop you are on becaus
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > If you start counting every line from the start of the current column,
> > > it will align correctly regardless of the previous columns.
> >
> > At this stage you don't
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Even if we knew the column position at output time, when we are doing
> > aligned column width computations, we don't know the width of the
> > previous columns so we would have no way to know how far the tab wo
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have implemented the following patch which outputs tab as a tab. It
> > also assumes a tab has a width of 4, which is its average width:
>
> That pretty much completely sucks; it will undo all the hard
unctions
-[ RECORD 1 ]---+
Schema | public
Name| xx
Result data type| text
Argument data types |
Volatility | volatile
Owner | postgres
Language| sql
Source code
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Added to TODO:
>
> > * Allow text search dictionary to filter out only stop words
>
> > http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php
>
> That's a poor description.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I don't think that follows. A tsearch index is lossy anyway, so there's
>
> > Uh, the index is lossy but I thought it was lossy
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> If we're going to change it, we should make it match GUC's parse_bool,
> >> which has had some actual thought put into it.
>
> > Good idea. Do I copy the
Bryce Nesbitt wrote:
> Bruce Momjian wrote:
> > I have updated the documentation for this patch. I consider it ready to
> > apply. I think it is as close to a middle ground as we are going to
> > get. Further adjustment will have to happen when we have more reports
>
.
---
Bruce Momjian wrote:
> I have moved this discussion to hackers in hopes of getting more
> feedback, and moved the patch to a static URL:
>
> ftp://momjian.us/pub/postgresql/mypatches/wrap
>
> This patch adds a new '\pset format wrapped' mode that wr
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > So, is this an option we want for configure?
>
> I think the case for it got a whole lot weaker in 8.3, with lazy
> consumption of CIDs. If someone had tables big enough to make the
> 32-bit-CID limit stil
m/users/%7Ejulo/media/pgss_debugging.png
>
> Also, there was some message a while back on pgsql-bugs from Len Zaifman
> requesting
> this as well.
>
> Cheers
>
> Julo
>
> --
> Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
> To make ch
1 - 100 of 4118 matches
Mail list logo
