Josh Berkus wrote:
Hackers,
Is there a reason why INTERVAL 'infinity' is not implemented? That is,
an interval which is larger than all defined intervals, and which added
to any timestamp turns it into 'infinity'.
Or is it just Round TUITs?
Probably the latter.
There is even a function |isf
On Nov 1, 2011, at 11:19 AM, Robert Haas wrote:
>> Fair enough.
>
> So, I tried to work up a patch for this, but I'm actually a bit
> confused about what needs to be done here. I'll attach what I've got
> so far as a starting point for discussion.
Looks reasonable, if verbose. (Yes, the extensi
"Eric B. Ridge" writes:
> However, why is
> select table.* foo from table
> allowed? What does that even mean?
Doesn't mean anything, I think --- the SQL standard seems to exclude it.
It's fairly hard to prevent it at the grammar level, since we regard
"foo.*" as a type of primitive express
looks like the v3 patch re-introduces the pg_subtrans issue...
On Tue, Nov 1, 2011 at 9:33 AM, Simon Riggs wrote:
> On Thu, Oct 27, 2011 at 4:25 PM, Simon Riggs
> wrote:
>
> > StartupMultiXact() didn't need changing, I thought, but I will review
> further.
>
> Good suggestion.
>
> On review, S
On Tue, Nov 1, 2011 at 9:11 PM, Josh Berkus wrote:
> On 11/1/11 12:29 PM, Robert Treat wrote:
>> "Starting in 9.2, you should use pg_ctl standby to launch your
>> database for normal operations and/or in cases where you are writing
>> init scripts to control your production databases. For backward
On Wed, Oct 19, 2011 at 3:58 PM, Simon Riggs wrote:
> On Wed, Oct 19, 2011 at 3:29 PM, Fujii Masao wrote:
>> On Wed, Oct 19, 2011 at 9:45 PM, Robert Haas wrote:
>>> I don't really see any reason to break the monitoring view just
>>> because we did some internal refactoring. I'd rather have back
* Marti Raudsepp (ma...@juffo.org) wrote:
> Unfortunately it's far less efficient. Fields would be truncated in
> psql, so full values are still detoasted and transmitted over the
> network.
I'm thinking that we're not too worried about performance of ad-hoc
psql queries..? At least, for the quer
On 11/1/11 12:29 PM, Robert Treat wrote:
> "Starting in 9.2, you should use pg_ctl standby to launch your
> database for normal operations and/or in cases where you are writing
> init scripts to control your production databases. For backwards
> compatibility, if you require the old behavior of usi
Hackers,
Is there a reason why INTERVAL 'infinity' is not implemented? That is,
an interval which is larger than all defined intervals, and which added
to any timestamp turns it into 'infinity'.
Or is it just Round TUITs?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent vi
On Tue, Nov 1, 2011 at 1:33 PM, Pavel Stehule wrote:
>> COPY (SELECT * EXCLUDING (a, b, c) FROM ) TO 'somefile.csv' WITH
>> CSV;
>>
> sorry, I don't accept it. I am able to understand your request for
> adhoc queries. But not for COPY.
I apologize if that example was confusing. I wasn't also su
I'm working on fixing the stale-toast-pointer problem discussed in
http://archives.postgresql.org/message-id/2348.1319591...@sss.pgh.pa.us
In that thread, it was pointed out that it's unsafe to fetch a toasted
value unless we are advertising a MyProc->xmin that's old enough to
prevent removal of t
On Thu, Oct 6, 2011 at 12:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> +1. However, if that's the route we're traveling down, I think we had
>> better go ahead and remove the one remaining => operator from hstore
>> in 9.2:
>
> Fair enough.
So, I tried to work up a patch for this, but I'm ac
On Tue, Nov 1, 2011 at 12:24 PM, Pavel Stehule wrote:
> some other idea - but only for psql
>
> we can define a special values, that ensure a some necessary
> preexecution alchemy with entered query
>
> \pset star_exclude_names col1, col2, col3
> \pset star_exclude_types xml, bytea, text(unlimited
2011/11/1 Robert Haas :
> On Tue, Nov 1, 2011 at 1:32 PM, Kohei KaiGai wrote:
>> I tried to summarize permission checks of DAC/MAC on several object classes
>> that are allowed to assign security label right now.
>> http://wiki.postgresql.org/index.php?title=SEPostgreSQL/Permissions
>>
>> In most
2011/11/1 Eric Ridge :
> On Tue, Nov 1, 2011 at 1:33 PM, Pavel Stehule wrote:
>>> COPY (SELECT * EXCLUDING (a, b, c) FROM ) TO 'somefile.csv' WITH
>>> CSV;
>>>
>> sorry, I don't accept it. I am able to understand your request for
>> adhoc queries. But not for COPY.
>
> I apologize if that example
On Tue, Nov 01, 2011 at 10:13:52AM -0400, Andrew Dunstan wrote:
>
>
> On 11/01/2011 09:52 AM, Tom Lane wrote:
> >Simon Riggs writes:
> >>Why not leave it exactly as it is, and add a previous_query column?
> >>That gives you exactly what you need without breaking anything.
> >That would cost twic
On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
> >> That would cost twice as much shared memory for query strings, and twice
> >> as much time to update the strings, for what seems pretty marginal
> >> value. I'm for j
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus wrote:
> So, we have four potential paths regarding recovery.conf:
>
> 1) Break backwards compatibility entirely, and stop supporting recovery.conf
> as a trigger file at all.
Note that is exactly what I have suggested when using "standby" mode
from
On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs wrote:
> On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus wrote:
>
>> So, we have four potential paths regarding recovery.conf:
>>
>> 1) Break backwards compatibility entirely, and stop supporting recovery.conf
>> as a trigger file at all.
>
> Note that i
On Nov 1, 2011, at 6:47 PM, Tom Lane wrote:
> I can think of a number of places where you can write "*" where I'm
> pretty sure we *don't* want this. It should be restricted to top-level
> entries in SELECT targetlists, IMO.
Yes. That is the exact conclusion I've come to.
However, why is
Eric Ridge writes:
> My original thought, that I probably didn't explain too clearly, was
> to make the "EXCLUDING (...)" bit a modifier to the A_Star node. The
> idea being that you could write "* EXCLUDING (...)" anywhere you can
> currently write "*".
I can think of a number of places where y
On Mon, Oct 31, 2011 at 09:14:48AM -0400, Andrew Dunstan wrote:
> The fact is that if you have 100 columns and want 95 of them, it's
> very tedious to have to specify them all, especially for ad hoc
> queries where the house SQL standards really don't matter that much.
> It's made more tedious by t
On 11/01/2011 09:52 AM, Tom Lane wrote:
Simon Riggs writes:
Why not leave it exactly as it is, and add a previous_query column?
That gives you exactly what you need without breaking anything.
That would cost twice as much shared memory for query strings, and twice
as much time to update the
On Tue, Nov 1, 2011 at 1:20 PM, Magnus Hagander wrote:
> On Tue, Nov 1, 2011 at 18:11, Scott Mead wrote:
>>
>> On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
>>>
>>> Robert Haas writes:
>>> > On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
>>> >> That would cost twice as much shared memory f
On Tue, Nov 1, 2011 at 9:55 AM, Robert Haas wrote:
> On Tue, Nov 1, 2011 at 10:47 AM, Marti Raudsepp wrote:
>> On Fri, Oct 28, 2011 at 20:58, Robert Haas wrote:
>>> I tried sprinkling a little branch-prediction magic on this code using
>>> GCC's __builtin_expect(). That initially seemed to help
On Tue, Nov 1, 2011 at 12:03 PM, Stephen Frost wrote:
> Note- I haven't looked at the * production or tried to do anything w/ gram.y
> to
> support this yet, but it's a heck of a lot shorter..
My original thought, that I probably didn't explain too clearly, was
to make the "EXCLUDING (...)" bit
On Tue, Nov 1, 2011 at 2:34 PM, Simon Riggs wrote:
> On Tue, Nov 1, 2011 at 6:12 PM, Robert Treat wrote:
>> On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs wrote:
>>> On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus wrote:
>>>
So, we have four potential paths regarding recovery.conf:
1)
On Tue, Nov 1, 2011 at 18:40, Scott Mead wrote:
>
>
> On Tue, Nov 1, 2011 at 1:20 PM, Magnus Hagander wrote:
>>
>> On Tue, Nov 1, 2011 at 18:11, Scott Mead wrote:
>> >
>> > On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
>> >>
>> >> Robert Haas writes:
>> >> > On Tue, Nov 1, 2011 at 9:52 AM,
On Tue, Nov 1, 2011 at 1:20 PM, Magnus Hagander wrote:
> On Tue, Nov 1, 2011 at 18:11, Scott Mead wrote:
> >
> > On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
> >>
> >> Robert Haas writes:
> >> > On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
> >> >> That would cost twice as much shared m
On Tue, Nov 01, 2011 at 10:55:02AM -0400, Robert Haas wrote:
> Well, the obvious problem is that we might end up spending a lot of
> work on something that doesn't actually improve performance, or even
> makes it worse, if our guesses about what's likely and unlikely turn
> out to be wrong. If we
2011/11/1 Eric Ridge :
> On Tue, Nov 1, 2011 at 12:24 PM, Pavel Stehule
> wrote:
>> some other idea - but only for psql
>>
>> we can define a special values, that ensure a some necessary
>> preexecution alchemy with entered query
>>
>> \pset star_exclude_names col1, col2, col3
>> \pset star_exclu
On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> > What I would prefer is to have the upgrade succeed, and just ignore
>> > the existence of a postgres database in the new cluster. Maybe give
>> > the user a notice and let them decide whether they wish to take any
>>
On 11/1/11 10:34 AM, Simon Riggs wrote:
> On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus wrote:
>
>> So, we have four potential paths regarding recovery.conf:
>>
>> 1) Break backwards compatibility entirely, and stop supporting recovery.conf
>> as a trigger file at all.
>
> Note that is exactly
On Tue, Nov 1, 2011 at 2:49 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> >> > It turns out there was only one place that expected a 1-1 mapping of old
>> >> > and new databases (file transfer), so I just modified that code to allow
>> >> > skipping a database in the new cluster that didn't exi
On Tue, Nov 1, 2011 at 1:32 PM, Kohei KaiGai wrote:
> I tried to summarize permission checks of DAC/MAC on several object classes
> that are allowed to assign security label right now.
> http://wiki.postgresql.org/index.php?title=SEPostgreSQL/Permissions
>
> In most of checks, required contextual
On Tue, Nov 1, 2011 at 18:11, Scott Mead wrote:
>
> On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane wrote:
>>
>> Robert Haas writes:
>> > On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
>> >> That would cost twice as much shared memory for query strings, and
>> >> twice
>> >> as much time to update t
Robert,
> In most cases we either break backwards compatibility or require some
> type of switch to turn on backwards compatibility for those who want
> it. While the above plan tries to do one better, it leaves me feeling
> that the thing I don't like about this is that it sounds like you are
> f
On Tue, Nov 1, 2011 at 2:36 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian wrote:
>> > Bruce Momjian wrote:
>> >> > What I would prefer is to have the upgrade succeed, and just ignore
>> >> > the existence of a postgres database in the new cluster.
On Tue, Nov 1, 2011 at 6:12 PM, Robert Treat wrote:
> On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs wrote:
>> On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus wrote:
>>
>>> So, we have four potential paths regarding recovery.conf:
>>>
>>> 1) Break backwards compatibility entirely, and stop supporting
Bruce Momjian wrote:
> > What I would prefer is to have the upgrade succeed, and just ignore
> > the existence of a postgres database in the new cluster. Maybe give
> > the user a notice and let them decide whether they wish to take any
> > action. I understand that failing is probably less code,
Robert Haas wrote:
> >> > It turns out there was only one place that expected a 1-1 mapping of old
> >> > and new databases (file transfer), so I just modified that code to allow
> >> > skipping a database in the new cluster that didn't exist in the old
> >> > cluster.
> >>
> >> Urp. ?But that mean
Robert Haas wrote:
> On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> > What I would prefer is to have the upgrade succeed, and just ignore
> >> > the existence of a postgres database in the new cluster. ?Maybe give
> >> > the user a notice and let them decide whe
Robert Haas wrote:
> On Tue, Nov 1, 2011 at 2:49 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> >> > It turns out there was only one place that expected a 1-1 mapping of
> >> >> > old
> >> >> > and new databases (file transfer), so I just modified that code to
> >> >> > allow
> >> >> > ski
2011/10/21 Robert Haas :
> On Fri, Oct 21, 2011 at 12:44 PM, Kohei KaiGai wrote:
>> I had checked my older implementation based on 8.4.x or 9.0.x that
>> includes all the features that I want to implement.
>> At least, it does not require so much different information from ones
>> needed by DAC mo
Peter Eisentraut writes:
> Here is a finalized patch for this. The first hunk of the patch is the
> documentation change, so you can see there how it's supposed to work.
> Let me know what you think.
+1
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et
2011/11/1 Eric Ridge :
> On Tue, Nov 1, 2011 at 12:24 PM, Pavel Stehule
> wrote:
>> some other idea - but only for psql
>>
>> we can define a special values, that ensure a some necessary
>> preexecution alchemy with entered query
>>
>> \pset star_exclude_names col1, col2, col3
>> \pset star_exclu
On Tue, Nov 1, 2011 at 6:36 PM, Josh Berkus wrote:
> On 11/1/11 10:34 AM, Simon Riggs wrote:
>> On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus wrote:
>>
>>> So, we have four potential paths regarding recovery.conf:
>>>
>>> 1) Break backwards compatibility entirely, and stop supporting
>>> recover
2011/11/1 Marti Raudsepp :
> On Mon, Oct 31, 2011 at 23:37, Scott Mead wrote:
>> So I wrote the attached patch, it just turns in transaction into:
>> " in transaction\n: Previous: ". After seeing
>> how quickly our dev's fixed the issue once they saw prepared statement XYZ,
>
> Solving this
On Tue, Nov 1, 2011 at 10:47 AM, Marti Raudsepp wrote:
> On Fri, Oct 28, 2011 at 20:58, Robert Haas wrote:
>> I tried sprinkling a little branch-prediction magic on this code using
>> GCC's __builtin_expect(). That initially seemed to help, but once I
>> changed the BufferIsValid() test to !Buff
On Fri, Oct 28, 2011 at 20:58, Robert Haas wrote:
> I tried sprinkling a little branch-prediction magic on this code using
> GCC's __builtin_expect(). That initially seemed to help, but once I
> changed the BufferIsValid() test to !BufferIsInvalid() essentially all
> of the savings disappeared.
On Mon, Oct 31, 2011 at 20:59, Magnus Hagander wrote:
> On Mon, Oct 31, 2011 at 20:58, Tom Lane wrote:
>> Magnus Hagander writes:
>>> So once again I forgot about the fact that you can specify multiple
>>> LDAP server in our ldapserver parameter (because both openldap and
>>> winldap accept a sp
Robert Haas writes:
> On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
>> That would cost twice as much shared memory for query strings, and twice
>> as much time to update the strings, for what seems pretty marginal
>> value. I'm for just redefining the query field as "current or last
>> query".
On 2011-11-01 21:13, Andrew Dunstan wrote:
Rename it please. "current_query" will just be wrong. I'd be inclined
just to call it "query" or "query_string" and leave it to the docs to
define the exact semantics.
I think "query" for a query that isn't ongoing would be just as wrong.
How about "
On Tue, Nov 1, 2011 at 1:48 PM, Tom Lane wrote:
> Simon Riggs writes:
>> The reason we run a shutdown checkpoint is to prevent needing to
>> re-enter recovery if we crash after promotion.
>
> That's *a* reason, it's not necessarily the only reason. This proposal
> worries me, especially your bli
On Tue, Nov 1, 2011 at 2:04 PM, Robert Haas wrote:
> On Tue, Nov 1, 2011 at 9:45 AM, Simon Riggs wrote:
>> Why do we have this log message then, if it is OK to ignore changes
>> that have no effect?
>>
>> LOG: parameter "shared_buffers" cannot be changed without restarting the
>> server
>
> I b
On Tue, Nov 1, 2011 at 1:23 PM, Robert Haas wrote:
> On Tue, Nov 1, 2011 at 8:14 AM, Simon Riggs wrote:
>> On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas wrote:
>>> On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs wrote:
If you change a parameter that only has effect during recovery then
mus
On Mon, Oct 31, 2011 at 23:37, Scott Mead wrote:
> So I wrote the attached patch, it just turns in transaction into:
> " in transaction\n: Previous: ". After seeing
> how quickly our dev's fixed the issue once they saw prepared statement XYZ,
Solving this problem is a good idea, but I don't
On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane wrote:
> Simon Riggs writes:
>> Why not leave it exactly as it is, and add a previous_query column?
>
>> That gives you exactly what you need without breaking anything.
>
> That would cost twice as much shared memory for query strings, and twice
> as much
On Tue, Nov 1, 2011 at 9:45 AM, Simon Riggs wrote:
> Why do we have this log message then, if it is OK to ignore changes
> that have no effect?
>
> LOG: parameter "shared_buffers" cannot be changed without restarting the
> server
I believe we're logging the fact that we were unable to make the
On Tue, Nov 1, 2011 at 1:52 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Why not leave it exactly as it is, and add a previous_query column?
>
>> That gives you exactly what you need without breaking anything.
>
> That would cost twice as much shared memory for query strings, and twice
> as much
Simon Riggs writes:
> Why not leave it exactly as it is, and add a previous_query column?
> That gives you exactly what you need without breaking anything.
That would cost twice as much shared memory for query strings, and twice
as much time to update the strings, for what seems pretty marginal
Simon Riggs writes:
> The reason we run a shutdown checkpoint is to prevent needing to
> re-enter recovery if we crash after promotion.
That's *a* reason, it's not necessarily the only reason. This proposal
worries me, especially your blithe dismissal of the timeline issues;
but in any case I wo
On Tue, Nov 1, 2011 at 8:41 AM, Magnus Hagander wrote:
> On Tue, Nov 1, 2011 at 13:19, Simon Riggs wrote:
>> On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas wrote:
>>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
>>> wrote:
Actually, for the future, it might be useful to have a "state"
On Tue, Nov 1, 2011 at 8:14 AM, Simon Riggs wrote:
> On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas wrote:
>> On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs wrote:
>>> If you change a parameter that only has effect during recovery then
>>> must get an error if it is changed during normal running.
>>
On Sat, Oct 29, 2011 at 5:26 PM, Eric Ridge wrote:
> Would y'all accept a patch that extended the "SELECT *" syntax to let
> you list fields to exclude from the A_Star?
>
> Quite regularly I'll be testing queries via psql and want to see all
> the columns from a fairly wide table except maybe a gi
On Tue, Nov 1, 2011 at 12:41 PM, Magnus Hagander wrote:
> On Tue, Nov 1, 2011 at 13:19, Simon Riggs wrote:
>> On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas wrote:
>>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
>>> wrote:
Actually, for the future, it might be useful to have a "state"
On Tue, Nov 1, 2011 at 13:19, Simon Riggs wrote:
> On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas wrote:
>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander wrote:
>>> Actually, for the future, it might be useful to have a "state" column,
>>> that holds the idle/in transaction/running status, ins
On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas wrote:
> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander wrote:
>> Actually, for the future, it might be useful to have a "state" column,
>> that holds the idle/in transaction/running status, instead of the
>> tools having to parse the query text to
On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas wrote:
> On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs wrote:
>> If you change a parameter that only has effect during recovery then
>> must get an error if it is changed during normal running.
>
> I don't see why. If you're in normal running and someon
When a server fails, we need to promote a standby as quickly as possible.
Currently when we promote a standby to a primary we need to run a
shutdown checkpoint before users can begin write transactions, which
in many cases can take minutes.
The reason we run a shutdown checkpoint is to prevent ne
On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs wrote:
> If you change a parameter that only has effect during recovery then
> must get an error if it is changed during normal running.
I don't see why. If you're in normal running and someone changes a
parameter that is irrelevant during normal runni
On Tue, Nov 1, 2011 at 7:38 AM, Magnus Hagander wrote:
> If we are doing it, it might be useful to just call it "query", so
> that it is dead obvious to people that the definition changed..
Yeah. Otherwise, people who are parsing the hard-coded strings
and are likely to get confused.
--
Robe
On Tue, Nov 1, 2011 at 5:59 AM, Fujii Masao wrote:
> On Mon, Oct 31, 2011 at 5:23 PM, Simon Riggs wrote:
>> On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao wrote:
>>
In 9.2 the presence of recovery.conf can and therefore should continue
to act as it does in 9.1.
>>>
>>> This means that re
On Tue, Nov 1, 2011 at 00:18, Scott Mead wrote:
>
>
> On Mon, Oct 31, 2011 at 6:13 PM, Robert Haas wrote:
>>
>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
>> wrote:
>> > Actually, for the future, it might be useful to have a "state" column,
>> > that holds the idle/in transaction/running s
On 1 November 2011 00:14, Andrew Dunstan wrote:
> On 10/30/2011 10:00 PM, Christopher Browne wrote:
>> I don't think I wish it. We're telling our developers not to use "select
>> *", and I don't think having "select * except " would change that policy,
>> beyond requiring us to waste time explain
On Mon, Oct 31, 2011 at 12:54, Marcin Mańk wrote:
> How about an option for psql to truncate too long columns to X characters ?
I would really want this in some form or another; for example, being
able to hide bytea values entirely, or set limits to how many
characters are displayed for fields.
I have not tried the patch (yet), but Informix'sl dbacess would do about
the same - and it's something I really missed.
Jan
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
78 matches
Mail list logo
