On Fri, May 02, 2008 at 07:19:00PM -0400, Tom Lane wrote:
Ultimately Michael's opinion is the one that matters most for ecpg
stuff, anyway. Michael?
Sorry for the late reply, real life constraints. I talked to Peter about
the patched before he sent out his first email. In fact I agree with
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, I looked into 'ls -C' hanlding a little more and ls (GNU coreutils)
5.97 honors COLUMNS _only_ in file/pipe output, not for screen output.
What the C code does is to read COLUMNS, then overwrite that value with
ioctl() if it works.
Well saying
On Sun, May 04, 2008 at 09:44:58PM +0200, Dimitri Fontaine wrote:
IIRC, I've read here in the past some attempts to begin a proposal on
the topic of data hints, allowing the user to describe his data in a
way ANALYZE can't figure out by itself, as e.g. this column value is
tied to this
Am Dienstag, 6. Mai 2008 schrieb Martijn van Oosterhout:
Cross-table correlations are easy for the second part, because it's
fairly simple to see where it could be used. However, no-one has come
up with an algorithm to produce a useful number to use. For others it's
harder.
For an algorithm,
Tom Lane [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
Are others OK with $COLUMNS controlling screen output and file/pipe, or
perhaps COLUMNS controlling only file/pipe, as GNU ls does? I have
heard a few people say they only want \pset columns to control
file/pipe.
I
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
Are others OK with $COLUMNS controlling screen output and file/pipe, or
perhaps COLUMNS controlling only file/pipe, as GNU ls does? I have
heard a few people say they only want \pset columns
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, I looked into 'ls -C' hanlding a little more and ls (GNU coreutils)
5.97 honors COLUMNS _only_ in file/pipe output, not for screen output.
What the C code does is to read COLUMNS, then overwrite that value with
ioctl()
* Bruce Momjian [EMAIL PROTECTED] [080506 10:56]:
What logic is there that GNU ls honors COLUMNS only in non-terminal
output? And the use of COLUMNS isn't even documented in the GNU ls
manual page. And BSD ls honors COLUMNS only for terminal output when
the ioctl fails(). It is hard to
Steve Crawford wrote:
My fingers sometimes run on autoappend semicolon mode and I end up
typing \pset pager always; instead of \pset pager always. No error
is returned, short (but wide) output is not routed to the pager, and I
have to back up and correct the \pset pager command. After some
Aidan Van Dyk [EMAIL PROTECTED] writes:
But one of the interesting things is that psql has an is *interactive*
mode (something the GNU utils don't have to worry about). So *when* you
choose to figure out your columns is important, and really impacts
behaviour too.
Well, COLUMNS has no hope
Bruce Momjian [EMAIL PROTECTED] writes:
So, I think the answer is that we have the current behavior because of
backward compatibility. Perhaps we should be more strict in
ParseVariableBool(), perhaps only allowing true/false and on/off.
If we're going to change it, we should make it match
Aidan Van Dyk wrote:
I have to admit to using the COLUMNS=... command trick myself.
I do have COLUMNS exported in my terminal, and often to stuff like:
ls -C | less
and I expect it to wrap at $COLUMNS (my terminal width) in my pager.
And since the GNU coreutils is pretty
Am Dienstag, 6. Mai 2008 schrieb Tom Lane:
Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
which is why the ioctl should take precedence over it.
Readline changes the value of COLUMNS on the fly.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Tom Lane wrote:
Aidan Van Dyk [EMAIL PROTECTED] writes:
But one of the interesting things is that psql has an is *interactive*
mode (something the GNU utils don't have to worry about). So *when* you
choose to figure out your columns is important, and really impacts
behaviour too.
Bruce Momjian [EMAIL PROTECTED] writes:
I just looked at coreutils-6.9 and 5.97 and neither manual has a mention
of COLUMNS. Seems this is some Debian manual addition or something. I
don't see it on Ubuntu 7.10 either.
You're looking in the wrong place. See info ls.
Peter Eisentraut wrote:
Am Dienstag, 6. Mai 2008 schrieb Tom Lane:
Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
which is why the ioctl should take precedence over it.
Readline changes the value of COLUMNS on the fly.
Yes, but my patch grabs COLUMNS before we
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Dienstag, 6. Mai 2008 schrieb Tom Lane:
Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
which is why the ioctl should take precedence over it.
Readline changes the value of COLUMNS on the fly.
... from the ioctl's
* Bruce Momjian [EMAIL PROTECTED] [080506 11:59]:
But one of the interesting things is that psql has an is *interactive*
mode (something the GNU utils don't have to worry about). So *when* you
choose to figure out your columns is important, and really impacts
behaviour too.
For
I have a client who is looking for a way to be able to alter objects
without having to recreate (say, from a dump) all the objects in a
possibly large dependency tree rooted at the object. Of course, if the
alteration invalidates the dependency, than this operation should fail,
but adding a
Andrew Dunstan wrote:
I have a client who is looking for a way to be able to alter objects
without having to recreate (say, from a dump) all the objects in a
possibly large dependency tree rooted at the object. Of course, if the
alteration invalidates the dependency, than this operation
Josh Berkus wrote:
Andrew Dunstan wrote:
I have a client who is looking for a way to be able to alter objects
without having to recreate (say, from a dump) all the objects in a
possibly large dependency tree rooted at the object. Of course, if
the alteration invalidates the dependency,
Andrew Dunstan [EMAIL PROTECTED] writes:
Josh Berkus wrote:
I don't follow you. I can currently add a column, without breaking
either foriegn keys or inheritance. What's the problem?
not for a view at least.
Yeah, the restrictions on replacing a view definition date from before
we had any
I wrote:
I tried to do a bit of testing of this, but it does not work on current
Fedora 8, because the policy module doesn't build:
I got past that by commenting out the last few lines of sepostgresql.te,
which apparently are intended for some SELinux feature that's not
shipped yet in F8.
On Tue, May 06, 2008 at 02:56:41PM -0400, Tom Lane wrote:
AFAICS the only thing left that really needs to be discussed more during
this commit-fest is the business about whether it's sane to be trying to
apply selinux restrictions in simple_heap_update and friends.
I don't have any opinion
Andrew Sullivan [EMAIL PROTECTED] writes:
I don't have any opinion about the patches, obviously, but I'm
wondering whether there is, somewhere, an outline of what the _goals_
of this system are.
The only documentation I've seen is
http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL
On Tue, May 06, 2008 at 03:28:25PM -0400, Tom Lane wrote:
The only documentation I've seen is
http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL
which contains only examples of enforcing restrictions on *user*
queries and tables.
I agree that, having just read that, anything that
Bruce Momjian wrote:
Updated patch with clearer documentation that matches the above
behavior:
ftp://momjian.us/pub/postgresql/mypatches/wrap
I found a bug in my patch, particularly related to wrapping to pipes.
Turns out if psql uses the pager internally:
\pset format
On Monday 05 May 2008 09:01:25 Andrew Dunstan wrote:
Zeugswetter Andreas OSB sIT wrote:
Do we want the following:
1. pg_dump issues set statement_timeout = 0; to the
database prior to
taking its copy of data (yes/no/default-but-switchable)
2. pg_dump/pg_restore issue set
Robert Treat [EMAIL PROTECTED] writes:
ISTR being unconvinced by the pg_restore arguments, but as I think about it
some more, for someone to set statement_timeout on a production system, and
then have that be blindly overridden by any random pg_dump user seems a bit
unfair. pg_dump is not
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
So, I think the answer is that we have the current behavior because of
backward compatibility. Perhaps we should be more strict in
ParseVariableBool(), perhaps only allowing true/false and on/off.
If we're going to change it, we
Andrew Sullivan [EMAIL PROTECTED] writes:
There is an issue in most high-security systems having to do with
side-channel leakage of supposedly sensitive data. So, the mere
exsistence of certain tables, columns, or users might be regarded as
security-sensitive data. I'm not sure I see how to
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
ISTR being unconvinced by the pg_restore arguments, but as I think about it
some more, for someone to set statement_timeout on a production system, and
then have that be blindly overridden by any random pg_dump user seems a bit
Magnus Hagander wrote:
On Wed, Mar 05, 2008 at 12:04:30PM -0500, Bruce Momjian wrote:
Gurjeet Singh wrote:
libpqxx seems to have moved around quite a bit. The attached patch
corrects
libpqxx's homepage.
Thanks, patch applied and back-patched to 8.3.X.
Do we really need to keep
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 C code into /psql or somehow share the
function?
Just copy it --- it's not large enough to
Greetings,
This really probably should have gone to -hackers rather than just back
to -patches, so here it is. Comments welcome.
* Tom Lane ([EMAIL PROTECTED]) wrote:
I'm not sure where we go from here. Your GSOC student has disappeared,
right? Is anyone else willing to take up the patch
While looking at the inherited-constraints patch I realized that the
CONSTROID syscache definition fails to list conrelid as a relation OID
column. What this means is that a relcache flush on a given relation
will fail to flush CONSTROID syscache entries for constraints belonging
to that rel.
Alex Hunsaker [EMAIL PROTECTED] writes:
[ patch to fix behavior of inherited constraints ]
Looking over this patch, I see that it introduces a syscache on
pg_constraint (conrelid, conname), which requires a unique index
underlying it. This is not workable because domain constraint
entries in
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
What I think would be a more desirable solution is that the table ACL
still sets the table-level INSERT or UPDATE privilege bit as long as
you have any such privilege. ...
I agree with this approach and feel it's
On Tue, May 6, 2008 at 7:57 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] writes:
[ patch to fix behavior of inherited constraints ]
Looking over this patch, I see that it introduces a syscache on
pg_constraint (conrelid, conname), which requires a unique index
Tom Lane wrote:
I'm not sure where we go from here. Your GSOC student has disappeared,
right? Is anyone else willing to take up the patch and work on it?
No, he has not disappeared at all. He is going to work on fixing issues
and getting the work up to SQL99
On Tue, 6 May 2008, Tom Lane wrote:
And of course the next question after that is why we should want to
depend on SELinux at all, rather than implementing row filtering in the
framework of SQL permissions...
It may be the case that clean row and column filtering at the SQL layer
are
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. I thought the TODO was something more like
allow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 6 mai 08 à 19:44, Tom Lane a écrit :
Andrew Dunstan [EMAIL PROTECTED] writes:
Josh Berkus wrote:
I don't follow you. I can currently add a column, without breaking
either foriegn keys or inheritance. What's the problem?
not for a
Tom, Thanks for your reviewing.
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
I updated the series of SE-PostgreSQL patches for the latest pgsql-8.4devel
tree.
I tried to do a bit of testing of this, but it does not work on current
Fedora 8, because the policy module doesn't
Dimitri Fontaine [EMAIL PROTECTED] writes:
Could we consider ALTER VIEW ALTER COLUMN ... SET DEFAULT ...;?
We could if we hadn't already done it five or so years ago.
Or am I missing what you need here?
Bonus question: why is the rewriter unable to distinguish whether NULL
comes from the
45 matches
Mail list logo
