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.
Yes
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 '
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
(1
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
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 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
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
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
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
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 or
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
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 code is
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
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
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.
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 once, and
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 UNIQUE
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 modern
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 is?
You
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.
Wonder if
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 provide
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 given
page
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 relatively longer
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 reason
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 of
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. (Not sure
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 languages,
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
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
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 name
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 for
What is ISTM?
Sorry,
Gustavo.
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
been
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. :-)
The
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 simple
It Seems To Me.
Heres 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 and
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
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
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. This could be
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 always be. But
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 something or I
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 logs
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
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:
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 0.77 to
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
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
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
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.
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 things in pg
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
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 is not how
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 security
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
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
client command, that is
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
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 output
patch?
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. Also
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
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 output
60 matches
Mail list logo
