On Fri, 25 Nov 2005, Bruce Momjian wrote:
> > > Is there any use for SHOW except in interactive psql sessions?
>
> There certainly is. Imagine querying for timezone. Also remember that
> pgadmin is a client application that is _not_ psql.
I should have written SHOW ALL, that's the command outp
The build order would be:
1. postgresql
2. php
3. plphp
There is not circular build dependency there.
Not only that, plphp does not require the building of php. It can link
directly to the .so file :)
Sincerely,
Joshua D. Drake
---(end of broadcast)-
Alvaro Herrera wrote:
> Dennis Bjorklund wrote:
>
> > My main problem with SHOW as it is in 8.1 is that the output is so wide
> > that it's very hard to read the output.
> >
> > Is there any use for SHOW except in interactive psql sessions?
There certainly is. Imagine querying for timezone. A
Alvaro Herrera wrote:
> > > I think a \show would be nice, but deprecating SHOW is out of the
> > > question. (The pg_settings view is a perfect replacement AFAICS but I
> > > doubt we can get rid of the old interface.)
> > >
> > > OTOH, what's the relationship between \show and Martijn's wide ou
Dennis Bjorklund wrote:
> My main problem with SHOW as it is in 8.1 is that the output is so wide
> that it's very hard to read the output.
>
> Is there any use for SHOW except in interactive psql sessions?
Nothing that can't be done by querying pg_settings.
--
Alvaro Herrera
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Dennis Bjorklund wrote:
> >
> > > > Actually, I'm going to implement a \show command and send to -patches
> > > > and
> > > > then SHOW can even be deprecated (if we want). SHOW is just a command
> > > > line
> > > > cli
On Fri, 25 Nov 2005, Bruce Momjian wrote:
> > OTOH, what's the relationship between \show and Martijn's wide output
> > patch? Maybe the problem can be solved in a different way.
>
> What does \show do that SHOW does not?
It could do several things. For example \show could omit the description
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Dennis Bjorklund wrote:
>
> > > Actually, I'm going to implement a \show command and send to -patches and
> > > then SHOW can even be deprecated (if we want). SHOW is just a command line
> > > client command, that is implemented in the server. That
John R Pierce wrote:
> Bruce Momjian wrote:
> > If someone wants to create a separate web page to track fixes related to
> > CVE number, that is fine. My guess is that most people reading the
> > release notes don't care about the CVE numbers themselves (just that
> > each release has all known se
On Fri, Nov 25, 2005 at 07:24:13PM -0300, Alvaro Herrera wrote:
> OTOH, what's the relationship between \show and Martijn's wide output
> patch? Maybe the problem can be solved in a different way.
None whatsoever. OTOH, there has been discussion about making use of
multiline output if it can be d
Bruce Momjian wrote:
> Dennis Bjorklund wrote:
> > Actually, I'm going to implement a \show command and send to -patches and
> > then SHOW can even be deprecated (if we want). SHOW is just a command line
> > client command, that is implemented in the server. That is not how we
> > normally do thin
> > > > We really should write the CVE numbers into the commit messages
> > > > and the release notes.
> > >
> > > I think that would be good.
> >
> > That requires the CVE number to be available at the time of commit.
> > Not sure if it'll always be. But if it is, it's certainly a
> good idea
Dennis Bjorklund wrote:
> I've noticed that in 8.1 the output of SHOW ALL includes a description
> column. This makes the output very wide which makes it hard to use from
> psql (I need to make the terminal window 164 characters wide to not get
> any line wrapping). I wish I would have noticed this
If someone wants to create a separate web page to track fixes related to
CVE number, that is fine. My guess is that most people reading the
release notes don't care about the CVE numbers themselves (just that
each release has all known security bugs fixed), and most bugs that are
fixed don't have
Andrew Dunstan wrote:
> I have no objection to this, but it's not clear to me that it buys much
> either. AFAIK only very modern PHP releases escape the circular dependency
> issue, no matter how we arrange our source code. What versions of PHP will
> PL/PHP be supporting?
Currently PL/php builds
Peter Eisentraut wrote:
> If you upgrade from PostgreSQL 8.0 to 8.1 you effectively also upgrade
> from "PL/pgSQL 8.0" to "PL/pgSQL 8.1". That's why we can and should
> and do alter the installation parameters of that language at the same
> time. But you don't necessarily upgrade from PL/foo
Andrew Dunstan wrote:
> I have no objection to this, but it's not clear to me that it buys
> much either. AFAIK only very modern PHP releases escape the circular
> dependency issue, no matter how we arrange our source code. What
> versions of PHP will PL/PHP be supporting?
The build order would be
On Fri, 2005-11-25 at 15:24 -0300, Gustavo Tonini wrote:
> What is "ISTM"?
Google tells me it stands for The Irish Society for Travel Medicine, but
it also gives a few other suggestions.
ISTM that google has the answer. :-)
Best Regards, Simon Riggs
---(end of broadcast
Simon Riggs <[EMAIL PROTECTED]> writes:
> Unless somebody else wants to do this, I'll discuss on -www how we can
> get a page up on the .org site with this info on, so that we can be "CVE
> compatible".
IMHO we should do that in any case, whether or not we mention CVEs
in our release notes or CVS
Peter Eisentraut said:
> Joshua D. Drake wrote:
>> Unless I missed something PLphp will be able to be in core (once it is
>> all cleaned up). At least
>> that was the last consensus that I read. My understanding was that it
>> just wouldn't compile
>> by default?
>
> Well, either you missed somethi
On Fri, Nov 25, 2005 at 07:30:12PM +0100, Magnus Hagander wrote:
> > > We really should write the CVE numbers into the commit messages and
> > > the release notes.
> >
> > I think that would be good.
>
> That requires the CVE number to be available at the time of commit. Not
> sure if it'll alwa
On Fri, 2005-11-25 at 12:20 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Fri, 2005-11-18 at 09:32 -0500, Tom Lane wrote:
> > > All known CVE problems are resolved in 8.0.4.
> >
> > It seems like we need a much clearer resource for security admins to
> > check our compliance levels. Thi
Magnus Hagander wrote:
> Point 2: CVE is pretty much the industry standard for naming
> vulnerabilities. This is what people *use*. There's no reason *not*
> to provide it as a cross reference. But sure, we shouldn't list only
> the ones that have CVE numbers - if there are any that doesn't, they
>
Bruce Momjian wrote:
> Why don't we have a libedit configure flag?
Well, I can code up a configure flag, but that doesn't mean that the
thing will compile at the end. :)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
Bruce Momjian wrote:
> I am not excited about referencing error numbers from someone else.
> We know our errors better than anyone else, so I don't see the point.
The point is, *we* might know our error numbers, but the rest of the
world doesn't.
And CVE isn't just "someone". A large number of
It Seems To Me.
Here’s a decent list of common
acronyms:
http://www.fun-with-words.com/acronyms.html
Mike Pollard
SUPRA Server SQL Engineering and Support
Cincom Systems, Inc.
Better to
remain silent and be thought a fool than to speak out
> > We really should write the CVE numbers into the commit messages and
> > the release notes.
>
> I think that would be good.
That requires the CVE number to be available at the time of commit. Not
sure if it'll always be. But if it is, it's certainly a good idea to put
it in.
> > How about a
Joshua D. Drake wrote:
> Unless I missed something PLphp will be able to be in core (once it
> is all cleaned up). At least
> that was the last consensus that I read. My understanding was that it
> just wouldn't compile
> by default?
Well, either you missed something or I missed something. :-)
Th
> > It seems like we need a much clearer resource for security
> admins to
> > check our compliance levels. This could be a source of similar
> > refusal-to-implement PostgreSQL at other installations, so could
> > almost be regarded as an advocacy issue. Other software
> projects have
> > be
What is "ISTM"?
Sorry,
Gustavo.
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The counterargument has been that a PostgreSQL major version
> > upgrade would typically require a version upgrade of all language
> > handlers. In my experience of maintaining and observing the
> > maintenance of binary packages f
On Fri, 25 Nov 2005, Tom Lane wrote:
>
> Is that "modern machine" a Xeon by any chance?
>
$#cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Pentium(R) 4 CPU 2.40GHz
I can find a 4way Xeon (but it is shared by many users):
/h/164/zhouqq#cat /proc/cpuinfo |grep "model name"
model
I just realized that this is the first out-of-core language for which
this has been proposed. I wonder why Joe Conway didn't submit an entry
for PL/R. (Is there any other language out there?)
Slightly off topic but:
Unless I missed something PLphp will be able to be in core (once it is
Simon Riggs wrote:
> On Fri, 2005-11-18 at 09:32 -0500, Tom Lane wrote:
> > All known CVE problems are resolved in 8.0.4.
>
> I was unaware of this. I've looked at the release notes and searched the
> archives, but this doesn't seem to be mentioned by CVE number. (The
> vulnerabilities and their
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The counterargument has been that a PostgreSQL major version upgrade
> would typically require a version upgrade of all language handlers. In
> my experience of maintaining and observing the maintenance of binary
> packages for PostgreSQL and langu
Jim C. Nasby wrote:
> On Mon, Nov 21, 2005 at 07:50:48PM -0500, Andrew Dunstan wrote:
> >
> > Nice analysis, but we can't hack configure like that. It has to be able
> > to be fully generated from its sources. I think the other source file
> > you would need to look at is config/programs.m4. (No
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Tue, Nov 22, 2005 at 10:07:15AM +0100, Zeugswetter Andreas DCP SD wrote:
> > PS: I'd prefer if readline was only linked where it is needed, namely in
> > psql.
>
> The problem as stated is that people don't want to maintain lists o
Alvaro Herrera wrote:
> Well, it's one step less for installing the language. Users just
> install the library and issue the appropiate CREATE LANGUAGE call; no
> need to mess with specifying the handler/validator function name.
> (Which is not a very big deal, granted, but it's precisely the reas
Le Vendredi 25 Novembre 2005 16:20, Tom Lane a écrit :
> Qingqing Zhou <[EMAIL PROTECTED]> writes:
> > I can see your computer is really slow, so my theory is that since it is
> > easy to hold a running-slowly horse than a fast one, so my spinlock on a
> > 2.4G modern machine should takes relativel
On Fri, 2005-11-25 at 09:54 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2005-11-24 at 23:48 -0500, Tom Lane wrote:
> >> Yeah, I was wondering the same. It'd be possible to rewrite the seqscan
> >> stuff so that we do the visibility tests for all the tuples on a giv
"R, Rajesh (STSD)" <[EMAIL PROTECTED]> writes:
> I have included the ipv6 auth. line in my pg_hba.conf file(::1/128) I
> keep getting error msgs from postmaster everytime I try to connect.
This is not the appropriate list to be asking basic support questions on.
Especially not when you don't provi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> Needs to return 0 or 1 though.
> All Boolean operators in MySQL do that, so to create an illusion of
> MySQL compatibility, you'd need to redefine all standard Boolean
> operators. I don't think you want that.
Won
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> test=# select null_safe_cmp (NULL,NULL);
>> ERROR: could not determine anyarray/anyelement type because input has
>> type "unknown"
>> Same casting problem due to anyelement, of course.
> Yes - I wonder what the trick to getting around that
Qingqing Zhou <[EMAIL PROTECTED]> writes:
> I can see your computer is really slow, so my theory is that since it is
> easy to hold a running-slowly horse than a fast one, so my spinlock on a
> 2.4G modern machine should takes relatively longer time to get effective.
> Just kidding.
Is that "moder
On Fri, Nov 25, 2005 at 09:14:47AM -0500, Jan Wieck wrote:
> Hmmm ... so you maintain that MERGE without an explicit LOCK TABLE, done
> by the user before performing the MERGE, can create duplicate rows (WRT
> the merge condition) and consequently raise a duplicate key error if
> there is a UNIQ
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2005-11-24 at 23:48 -0500, Tom Lane wrote:
>> Yeah, I was wondering the same. It'd be possible to rewrite the seqscan
>> stuff so that we do the visibility tests for all the tuples on a given
>> page at once, taking the buffer content lock just onc
Atsushi Ogawa <[EMAIL PROTECTED]> writes:
> I reproduced the problem by loading this dump to 8.1.0.
> I think that the problem is the same as this:
> http://archives.postgresql.org/pgsql-hackers/2005-11/msg01016.php
Good catch --- I agree that bug probably explains it.
reg
> I am attempting to override the default installation
> directory that the postgres MSI uses. I'm not familiar with
> MSI, but from what I've read I can specify properties on the
> command line to change properties in the installer? I've
> tried a variety of properties from looking at the
> i
On 11/25/2005 7:14 AM, Martijn van Oosterhout wrote:
On Thu, Nov 24, 2005 at 11:11:34AM -0500, Jan Wieck wrote:
I guess you misunderstood. [...]
But I'm not sure we're supposed to handle that case anyway. Oracle at
least doesn't require an index on the table being merged. And if I look
at it f
Peter Eisentraut wrote:
> Tom Lane wrote:
> > I don't see any strong reason for enforcing that as policy, if the
> > language maintainer wants an entry. (But is Alvaro the maintainer of
> > pl/php?)
Yes, I have started work on PL/php and currently I'm the only
maintainer. I must add that the cod
Hello:
I am attempting to override the default installation directory that the
postgres MSI uses. I'm not familiar with MSI, but from what I've read I
can specify properties on the command line to change properties in the
installer? I've tried a variety of properties from looking at the
inst
On Thu, Nov 24, 2005 at 11:11:34AM -0500, Jan Wieck wrote:
> On 11/24/2005 1:30 AM, Martijn van Oosterhout wrote:
> >Umm, if there are any errors you abort the transaction, just like any
> >other case. ACID requires that either the whole statement is done, or
> >none. If a trigger causes the INSERT
Hello there,
I have included the ipv6 auth. line in my pg_hba.conf file(::1/128)
I keep getting error msgs from postmaster everytime I try to
connect.
Going by previous posts on the topic am unable to conclude.
Does this mean pg 8.0.3 doesn't support ipv6 client auth. ??
Or is there a patch som
Hello there,
I have included the ipv6 auth. line in my pg_hba.conf file(::1/128) I
keep getting error msgs from postmaster everytime I try to connect.
Going by previous posts on the topic am unable to conclude.
Does this mean pg 8.0.3 doesn't support ipv6 client auth. ??
Or is there a patch s
On Thu, 2005-11-24 at 23:48 -0500, Tom Lane wrote:
> > What's more, we can see that for each row, a LWLock pair is invoked. So on
> > a more aggressive thought, can we change it to page level?
>
> Yeah, I was wondering the same. It'd be possible to rewrite the seqscan
> stuff so that we do the v
I reproduced the problem by loading this dump to 8.1.0.
I think that the problem is the same as this:
http://archives.postgresql.org/pgsql-hackers/2005-11/msg01016.php
I saw heap_tuple_toast_attrs() overwrites a new tuple. And, backend
crashed while executing ExecInsertIndexTuples().
The problem
Hello there,
I run Postgresql 8.0.3 on Tru64 Unix m/c.
I have included the ipv6 auth. line in my pg_hba.conf file(::1/128) I
keep getting error msgs from postmaster everytime I try to connect.
Going by previous posts on the topic am unable to conclude.
Does this mean pg 8.0.3 doesn't support i
Christopher Kings-Lynne wrote:
> Needs to return 0 or 1 though.
All Boolean operators in MySQL do that, so to create an illusion of
MySQL compatibility, you'd need to redefine all standard Boolean
operators. I don't think you want that.
--
Peter Eisentraut
http://developer.postgresql.org/~pet
On Nov 25, 2005, at 17:06 , Christopher Kings-Lynne wrote:
test=# select null_safe_cmp (NULL,NULL);
ERROR: could not determine anyarray/anyelement type because
input has type "unknown"
test=# select null_safe_cmp (NULL::integer,NULL::integer);
null_safe_cmp
---
1
(
CREATE OR REPLACE FUNCTION null_safe_cmp (ANYELEMENT, ANYELEMENT)
RETURNS INTEGER IMMUTABLE
LANGUAGE SQL AS $$
SELECT CASE
WHEN NOT ($1 IS DISTINCT FROM $2) THEN 1
ELSE 0
END;
$$;
Even cooler:
CREATE OR REPLACE FUNCTION null_safe_cmp(anyelement, anyelement)
RETURNS integer AS '
SELECT
test=# select null_safe_cmp (NULL,NULL);
ERROR: could not determine anyarray/anyelement type because input has
type "unknown"
test=# select null_safe_cmp (NULL::integer,NULL::integer);
null_safe_cmp
---
1
(1 row)
Same casting problem due to anyelement, of course.
Ye
61 matches
Mail list logo
