mething, basically like today's explain but with more "rationale"
included. This could be immensely useful to many Postgres users.
I'd even be willing to chip in a couple hundred bucks if it would help
grease the wheels for somebody taking up the challenge if that helps
at all :)
Tha
> I don't think it would be horrifically hard to change the way toast OIDs
> are assigned (I'm thinking we'd basically switch to creating a sequence
> for every toast table), but I don't think anyone's ever tried to push
> toast hard enough to hit this kind of limit.
I'd be interested in promoting
On 4/27/15, Jim Nasby wrote:
> On 4/25/15 1:19 PM, Bruce Momjian wrote:
>> Note if you are storing a table with rows that exceed 2KB in size
>> (aggregate size of each row) then the "Maximum number of rows in a
>> table" may be limited to 4 Billion, see TOAST.
>
> That's not accurat
mance start
degrading the same way. And there would still be the hard 4B limit.
Perhaps the foreign key to the TOAST table could be changed from oid
(32 bits) to something else (64 bits) [as well the sequence] so that
it never wraps? What do you think? And would a more aggressive change
like this have a chance of being accepted into the code base?
Thanks.
-roger-
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/30/15, Jim Nasby wrote:
> On 1/30/15 11:54 AM, Roger Pack wrote:
>>>> On 1/29/15, Roger Pack wrote:
>>>>> Hello. I see on this page a mention of basically a 4B row limit for
>>>>> tables that have BLOB's
>>>>
>>>> Oo
Oops forgot to forward to the list (suggestion/feature request to the
list admin for the various pg lists: make the default "reply to" go to
the list, not the sender, if at all possible).
Response below:
On 1/30/15, Jim Nasby wrote:
> On 1/30/15 11:54 AM, Roger Pack wrote:
&g
>> On 1/29/15, Roger Pack wrote:
>>> Hello. I see on this page a mention of basically a 4B row limit for
>>> tables that have BLOB's
>>
>> Oops I meant for BYTEA or TEXT columns, but it's possible the
>> reasoning is the same...
>
>
ected-hibernate-problems
One way of fixing this would be to allow "do instead" rules on normal
tables, instead of only on views (otherwise we are forced to use a rule,
correct me if I'm wrong). I'd wager there would be other viable options as
well.
Thanks!
-roger-
[1]
http:
considered adding "--no-location" to XGETTEXT_OPTIONS in
po/Makevars? This stops the massive churn through line renumbering
changes.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http
special support for it.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 40
.
[we do in reality have a small overcommit allowance to permit
efficient fork(2), but it's tiny and (in this context) irrelevant]
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux?
s would be a big issue or not.
It should also be possible to use VT100 line drawing characters for most
common terminal emulators (xterm and compatible), which would give line
drawing characters independent of locale. But this is terminal-
dependent.
Regards,
Roger
--
.''`. Roger
s. I couldn't tell from looking over the patch whether or
not you were already taking this into account though?
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://
er the
past few years, I also found that the various tools to do the
conversion do have their own issues (such as cvsps) which can lead to
incorrect history in some corner cases. Unfortunately, in any big
repo with a lot of history, you do tend to find you trip up on them
in a few places.
ould it make more sense just to add a boolean pset
parameter to enable/disable the use of wrap/newline marks? It may
be that people may wish to disable it for use cases in addition
to EXPLAIN.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http
On Wed, Nov 25, 2009 at 11:34:35PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > The following patch adds in an nl_langinfo(CODESET) check in
> > addition to the existing client encoding check.
>
> I think the consensus is pretty clear that we should just set the
> de
locale and Windows) would find this patch should
ensure psql will continue default to ASCII output. This will
fix the -l/-c problem for them as well.
Regards,
Roger
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 69d5814..8916ffa 100644
--- a/src/bin/psql/print.c
+++ b/src/bin
On Tue, Nov 24, 2009 at 05:43:00PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
> >> I wonder whether the most prudent solution wouldn't be to prevent
> >> default use of linestyle=unicode if ~/.psql
client encoding (such as myself ;-)
This should be a one-liner patch to update the existing check.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.source
On Sun, Nov 15, 2009 at 12:50:14AM +, Roger Leigh wrote:
> On Sat, Nov 14, 2009 at 01:31:29PM -0500, Tom Lane wrote:
> > Roger Leigh writes:
> > > The side effect from this change is that some of the testsuite
> > > expected data will need updating due to the extra
On Sat, Nov 14, 2009 at 01:31:29PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > The side effect from this change is that some of the testsuite
> > expected data will need updating due to the extra pad spaces
>
> No, we are *not* doing that. Somebody made a change to the
On Sat, Nov 14, 2009 at 05:40:24PM +, Roger Leigh wrote:
> On Mon, Nov 09, 2009 at 05:40:54PM -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Greg Stark writes:
> > > > While i agree this looks nicer I wonder what it does to things like
> > > &g
quot;." in place of
carriage return and ellipsis symbols.
- All the above is documented in the SGML documentation, including
the old style, which I always found confusing.
For comparison, I've included a transcript of all three linestyles
with a test script (also atta
On Sat, Oct 31, 2009 at 12:25:22PM -0400, Andrew Dunstan wrote:
>
>
> Roger Leigh wrote:
>>
>> Wouldn't it be much simpler all around to add a "csv" output format
>> in addition to the above for this purpose? Spreadsheets can read
>> it in with n
psql output formats (aligned, unaligned) are for
human-readable output and the others (latex, html, troff-ms) are
marked up for the respective tools. None of these are really
useful for other programs to parse.
Wouldn't it be much simpler all around to add a "csv" output format
in ad
d an additional ascii format such as "ascii-clean"
which cleans up the inconsistencies in the formatting as for the
unicode format, while the existing ascii format would remain the
default for backwards compatibility.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU
On Mon, Oct 26, 2009 at 11:33:40PM +, Roger Leigh wrote:
> On Mon, Oct 26, 2009 at 07:19:24PM -0400, Tom Lane wrote:
> > Roger Leigh writes:
> > > On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
> > >> Yeah. We can do what we like with the UT
On Mon, Oct 26, 2009 at 07:19:24PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
> >> Yeah. We can do what we like with the UTF8 format but I'm considerably
> >> more worried about the aspect of making
some termios fiddling, could that be at fault
or is that just readline ncurses initialisation?
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
On Sun, Oct 25, 2009 at 11:48:27PM +, Roger Leigh wrote:
> There's just one tiny display glitch I can see, and that's if you have
> mixed wrapping and newlines, you miss the lefthand wrap mark if the line
> is the last wrapped line and it ends in a newline. It might not be
On Sat, Oct 24, 2009 at 06:23:24PM +0100, Roger Leigh wrote:
> On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote:
> > I like the new Unicode tables, but the marking of continuation lines
> > looks pretty horrible:
> >
> > List
nse of not perfectly preserving output. The ASCII
rules are a little more compatible than the Unicode rules, but both
do break things a little. If the data lines do not contain either
newlines or wrapped text, then the output will remain unchanged.
Any feedback would be appreciated.
Regards,
Roger
-
in the next week or so,
in time for the next CommitFest, if you agree with the general idea.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.ne
On Tue, Oct 13, 2009 at 05:08:20PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > The attached updated patch renames all user-visible uses of
> > "utf8" to "unicode". It also updates the documentation
> > regarding "locale" to "psql clie
d updated patch renames all user-visible uses of
"utf8" to "unicode". It also updates the documentation
regarding "locale" to "psql client character set encoding"
so the docs now match the code exactly.
Regards,
Roger
--
.''`. Roger Leig
On Tue, Oct 06, 2009 at 10:44:27AM +0100, Roger Leigh wrote:
> On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> > Roger Leigh writes:
> > > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> > >> Elsewhere in the psql code, notably in m
On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> >> Elsewhere in the psql code, notably in mbprint.c, we make the decision
> >> on whether to apply certain Unicod
can handle UTF-8 when the client encoding is
UTF-8.
I have attached an updated patch which implements your suggested
behaviour. It also renames the option to "linestyle" rather than
"tablestyle" which I think represents its purpose a bit more clearly.
Thanks,
Roger
--
.&#
On Fri, Oct 02, 2009 at 05:34:16PM -0700, Brad T. Sliger wrote:
> On Friday 02 October 2009 04:21:35 Roger Leigh wrote:
> > I have attached a patch which implements the feature as a pset
> > variable. This also slightly simplifies some of the patch since
> > the table style i
On Wed, Sep 30, 2009 at 06:50:46PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> >> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
> >>> Thinking about this some more, ISTM a much better way of approaching
> >>> it would be to provide a
ting/-G option to psql (naming isn't my forté,
so feel free to change it!). This is also documented in the
SGML docs, and help text. Lastly, this option is used when invoking
psql by pg_regress, which results in a working testsuite in a UTF-8
locale.
Hopefully this is OK! I'
On Tue, Sep 29, 2009 at 04:32:49PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> >> C locale means POSIX behavior and nothing but.
>
> > Indeed it does. However, making LC_CTYPE be UTF-8 rather than
> > ASCII is both possible and still strictly conforming to the
use and not break the tests--
this is really just breaking an assumption in the testing code that
the test output will always be ASCII.
Forcing the LC_CTYPE to C will force ASCII output and work around this
problem with the tests. Another approach would be to let psql know
it's being run i
On Tue, Sep 29, 2009 at 01:41:27PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> > In Debian, we do have plans to introduce a C.UTF-8 locale,
>
> Egad, isn't that a contradiction in terms?
Not entirely!
> C locale means POSIX behavior and nothing but.
Indeed it
UTF-8 locale, and perhaps
eventually move the C locale to using UTF-8 by default, at which point
the tests would again fail because you would still get the UTF-8
formatting despite all of the LC_ etc. munging. (At that point, we
would have a C.ASCII for compatibility.)
Regards,
Roger
--
nt seem to be false positives. The
> regression tests pass against the new patch.
I've attached a new patch which tidies up those extra commas, plus
a patch showing the changes from the previous patch.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux
through the loop, and it's reached
zero after completion of the inner loop, so all of the code used when
curr_nl_line is > 0 is never called. I'm sure I'm interpreting this
incorrectly, but I can't see under what circumstances I would get the
column name header li
On Tue, Aug 25, 2009 at 10:32:50PM -0400, Alvaro Herrera wrote:
> Roger Leigh escribió:
>
> > An updated copy of the patch is attached.
>
> Did you give expanded output a look? (\x) I find it a bit weird that
> the first line shows a single-pixel wide line but the subseque
On Sun, Aug 23, 2009 at 06:33:49PM -0400, Alvaro Herrera wrote:
> Roger Leigh escribió:
>
> > +#if (defined(HAVE_LANGINFO_H) && defined(CODESET))
> > + if (!strcmp(nl_langinfo(CODESET), "UTF-8"))
> > + text_format = &utf8format;
> >
On Sun, Aug 23, 2009 at 11:47:02AM -0400, Alvaro Herrera wrote:
> Roger Leigh wrote:
> > Convert print_aligned_text, and its helper function, to use
> > table formatting in place of hardcoded ASCII characters.
>
> > @@ -841,7 +856,10 @@ print_aligned_text(const printTableC
On Sun, Aug 23, 2009 at 01:49:02AM +0100, Roger Leigh wrote:
> On Sat, Aug 22, 2009 at 07:42:10PM -0400, Robert Haas wrote:
> > On Sat, Aug 22, 2009 at 2:13 PM, Roger Leigh wrote:
> > > Further minor cleanups to tweak column alignment in a corner case,
> > > and to corre
On Sat, Aug 22, 2009 at 07:42:10PM -0400, Robert Haas wrote:
> On Sat, Aug 22, 2009 at 2:13 PM, Roger Leigh wrote:
> > Further minor cleanups to tweak column alignment in a corner case,
> > and to correct indentation to match the rest of the code.
>
> Please read the gu
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 7505cd4..9dec77d 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -356,6 +356,30
Further minor cleanups to tweak column alignment in a corner case,
and to correct indentation to match the rest of the code.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on G
Correct a corner case where the middle column separator overlaps
the right edge of the record number.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index be81adc
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index c6394ad..10faeb3 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1154,10 +1154,10
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index e4e9f01..be81adc 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1014,7 +1014,7
worth mentioning.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature
Default to using the ASCII table. However, if a UTF-8
locale codeset is in use, switch to the UTF-8 table.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index
Convert print_aligned_vertical, and its helper function, to use
table formatting in place of hardcoded ASCII characters.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 141 +++---
1 files changed, 87 insertions(+), 54 deletions(-)
diff --git
Small followup patch to correct expanded=1 and border=0 output
as mentioned in previous email.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourcefor
Convert print_aligned_text, and its helper function, to use
table formatting in place of hardcoded ASCII characters.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 50 +-
1 files changed, 37 insertions(+), 13 deletions(-)
diff --git a
print_aligned_text and print_aligned_vertical, and their
helper fuctions pass the table formatting and (where
applicable) line style information to allow correct
printing of table lines.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 23 ++-
1 files changed, 14
er=0 and expanded=1, which I just noticed while
sending this mail. I'll tidy that up and send another patch.
This is something I really think makes psql more readable and more
usable, which I've been working on over the last couple of nights, and
so here it is for your comments and criti
rules (lrule), allowing specification of line
styles for the top, middle and bottom horizontal lines in a table.
The other printTextFormat members, hrule and vrule define the
formatting needed to draw horizontal and vertical rules.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.h | 21
On May 5, 1:34 am, [EMAIL PROTECTED] (Peter Eisentraut) wrote:
> roger wrote:
> > Where can I configure which version (or path) that postgres will use?
>
> It uses whatever "python" program it can find first in the path. If
> your observation is different, please s
o use (and since it's "untrusted" anyways...), correct?
Many thanks if anyone can shed some light on this.
-Roger
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
ELECT fieldone FROM testtable;
-- CamelCase
SELECT FieldOne FROM TestTable;
-Roger
> Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
of interest, you are welcome to include this in your
libpqxx library, or as a separate project on GBorg (I'll relicense it
under the standard Postgres licence).
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
of interest, you are welcome to include this in your
libpqxx library, or as a separate project on GBorg (I'll relicense it
under the standard Postgres licence).
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
love to have a copy of that script that backups
postgre remotely.
angel
Hi all,
Can anyone point the doc explaining how to assign a new admin level
account name and password? I can't seem to find it in docs or search
engines. Thanks.
R. Smith
72 matches
Mail list logo
