Am Freitag, 11. Juli 2008 schrieb Fred Perniss:
> In Postgres the switch add_mising_from=on the SQL-Command
>
> DELETE FROM t2
> WHERE (t2.t2_t1_id=t1.t1_id)
> AND t1.t1_inhalt=5
> ;
>
> works (with message in Log).
>
> If the switch add_missing_from=off following Error-Message will be promted:
>
>
Am Tuesday, 22. July 2008 schrieb valgog:
> Why Postgres allows creating UNICODE database with the locale, that
> can possibly corrupt my data?
It doesn't allow it, as of 8.3. In 8.2 it does, but we have fixed that, for
the reasons that are becoming obvious to you now.
Perhaps part of the probl
Am Thursday, 7. August 2008 schrieb Tom Lane:
> I rather wonder whether -L has any reason to live at all. initdb's
> default is to locate PGSHAREDIR relative to where it finds the backend
> executable, which is consistent with what the backend itself is going
> to do. Is there any scenario where
Am Saturday, 9. August 2008 schrieb Richard Evans:
> I've made a couple of patches, for 8.3.3 and 8.2.9, which enable cross
> compilation for windows (mingw32) from a unix platform.
This looks good, with a couple of tweaks. I don't think we are going to be
making these kinds of changes in the 8.
Am Friday, 15. August 2008 schrieb Tariq Aziz:
> I have installed PostGRESql 8.3 and try in to retrieve data in xml
> format for which I need to use function "xmlAgg". but that's not
> supported in the instance I have configured. Kindly guide me If there is
> some service pack or patch required to
Am Friday, 15. August 2008 schrieb Grigory Zinin:
> We can create SERIAL field. But INTEGER type will be really set. It's well
> known that INTEGER field doesn't match values more than 4 bytes. But
> related SEQUENCE object has a 8 byte value.
> It looks strange for me that 4 bytes of these 8 byte
Dan Kaminsky wrote:
> >> 1) No roots (but still works for some unknown reason)
> >> 2) Explicitly configured corporate roots
> >> 3) Explicitly configured corporate roots, AND global roots
> >> 4) Global roots (but still works for some unknown reason)
> So, if you do nothing special, it's #1? Sou
[EMAIL PROTECTED] wrote:
> Is this possible?
That is a question, not a bug.
But yes, it is possible.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Richard Evans wrote:
> I'm not sure why the makefiles need the current directory. pwd -W is
> specific to mingw, I think it gives the directory in windows format. It
> has to be changed for cross compilation otherwise you get errors.
What does $(CURDIR) resolve to on mingw? Try the following mak
[EMAIL PROTECTED] wrote:
> 1. Install Perl v5.10
> 2. Install PG
> 3. PG does not see that machine has Perl
> 4. Remove Perl and PG
> 5. Instll Perl v5.8
> 6. Install PG
> 7. PG work fine
> Problem is that PG does not recognize Perl v5.10 =(
Please provide the actual commands and the actual output
Zahid Khan wrote:
> Hi ,
>
> I see one issue pg 8.3.3 .
>
> 1.
> According to the documentation of pg "The double precision type
> typically has a range of around 1E-307 to 1E+308 with a precision of at
> least 15 digits".
>
> ref:-
> http://www.postgresql.org/docs/8.3/static/datatype-numeric.htm
On Monday 25 August 2008 13:29:14 [EMAIL PROTECTED] wrote:
> ERROR: encoding LATIN2 does not match server's locale en_AU.UTF-8
> DETAIL: The server's LC_CTYPE setting requires encoding UTF8.
In 8.3, it no longer works to create databases of different or incompatible
encodings. You need to pick
Thomas H. wrote:
> maybe its by design (to not insert badly encoded characters into the
> utf8 encoded logs)? nevertheless to debug those faulty programm/codes,
> it would help to see what query provokes the error...
Well, the problem is mainly that there is no query, because the bytes arriving
a
Cindy Moore wrote:
I looked through the lists and couldn't figure out where else to put
this. I'm trying to create indices on xpath expressions for columns
of type xml.
I'm running postgres version 8.3.3, running on solaris.
Text=# create index trclass on lsj_xml ((xpath
('//[EMAIL PROTECTED]"t
Andreas Peer wrote:
Well, the use case is a strange one... I would like to use a varchar()
column for storing a variable-length vector of integers. The numbers are
represented by the codepoints. Therefore, I need to sort them as binary
data, not as characters. I would often need to get all the
David Fetter wrote:
On Sun, Sep 28, 2008 at 11:51:49AM -0700, austijc wrote:
That's going to be a problem for the continued viability of
Postgres.
Funny, I thought running a DBMS over a known-unreliable storage system
was a problem for the continued viability of Oracle. When, not if,
people l
ivocs admin wrote:
initdb -E ISO-8859-1 -D data/
This is probably not a good idea. You should specify a locale and let
initdb figure out the matching encoding. Otherwise you might end up
with an incompatible locale/encoding combination. (initdb would
probably not even allow this to procee
Jussi Pakkanen wrote:
However when I try to count the amount of distinct codes, I get this:
EXPLAIN SELECT COUNT(DISTINCT code) FROM log;
QUERY PLAN
-
Aggregate (cost=100801488.
Dmitry Orlov wrote:
if I issue create tablespace user_ts location
'/var/lib/postgresql/8.3/main/pg_tblspc' then appears nested links in
/var/lib/postgresql/8.3/main/pg_tblspc. So should avoid to create
tablespaces in pg_tblspc
If this is the location you give it, why should it avoid creating
t
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
ivocs admin wrote:
The database cluster will be initialized with locale uk_UA.KOI8-U.
could not determine encoding for locale "uk_UA.KOI8-U": codeset is "KOI8-U"
initdb: could not find suitable text searc
Tony Marston wrote:
The following bug has been logged online:
Bug reference: 4465
Logged by: Tony Marston
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: Windows XP
Description:GROUP BY is not to SQL standard
Details:
The Postgresql im
Tony Marston wrote:
I think your definition of "Feature T301 Functional Dependencies" is
extremely questionable. A functional dependency in relational theory
automatically exists where a non-key column on a table is functionally
dependent on the key of that table. It is not something that can be
Tony Marston wrote:
You are still missing the point - "functional dependencies" is not a
separate module that can be turned on or off with code,
It is in the SQL standard.
they are inherent in
the database design. According to relational theory any non-key field on a
table is functionally dep
Harvey, Allan AC wrote:
Zdenek,
Hmm, It does not look good. Your OS does not return proper
information about
codeset. Following code is broken:
setlocale(LC_CTYPE, ctype);
sys = nl_langinfo(CODESET);
sys = strdup(sys);
See
http://www.opengroup.org/onlinepubs/00969539
Kevin Field wrote:
Section 9.2 in the docs say, 'The ordinary comparison operators yield null
(signifying "unknown") when either input is null.' This applies to other
operators too. For example, the result of tacking an unknown value onto a
known one is unknown, because you don't know what exac
Tom Lane wrote:
It's really all kind of messy ... we need to trade off simplicity of
definition, ease of use, backwards compatibility, and standards
compliance (though the standard has only 1-D arrays so it's of just
limited help here).
AFAICT, the standard would certainly allow a type specific
Sushil wrote:
I am trying to exploit XML features of PostgreSQL 8.3.0 DB.
You should upgrade to the latest 8.3 release, currently 8.3.5. There
were some fixes in this area (and other areas).
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscriptio
Sushil wrote:
*postgres: postgres testdb [local] SELECT: symbol lookup error:
postgres: postgres testdb [local] SELECT: undefined symbol:
xmlNewTextWriterMemory*
Your problem appears to be here. Check you libxml installation. Maybe
someone forgot to export this symbol.
--
Sent via pgsql-
On Monday 24 November 2008 23:37:02 Barry Reddy wrote:
> Can anyone clarify if this apparent contradiction is an oversight ? Old
> documentation with new archiving documentation patched on, with no
> attention paid to the seeming contradiction on guidelines for filesystem
> backups of a running PG
On Friday 28 November 2008 15:31:51 Barry Sanford wrote:
> looking at PostgreSQL, I noticed that you have various geometric data types
> as standard. However, I was somewhat surprised that you are attempting to
> implement the 'line' type via a two point scheme. While this is okay for
> line segm
On Thursday 04 December 2008 13:03:16 wstrzalka wrote:
> This is my output on Windows:
> ---
>-
> D:\Code>pg_dump -U postgres -d test -n public
> pg_dump: too many command-line arguments (first
On Sunday 07 December 2008 01:02:05 Bruce Momjian wrote:
> Where are we on this?
Some of this has been fixed. But a lot of the code has been moved around
between 8.3 and 8.4, so we can't just take take the patches as is. If
Richard is still interested, I suggest he try out 8.4 and then submit
Vincent Predoehl wrote:
I was running fink and it said to report this:
configure: WARNING: krb5.h: present but cannot be compiled
configure: WARNING: krb5.h: check for missing prerequisite headers?
configure: WARNING: krb5.h: see the Autoconf documentation
configure: WARNING: krb5.h: sec
On Saturday 20 December 2008 02:15:05 Vincent Predoehl wrote:
> On Dec 19, 2008, at 3:48 AM, Peter Eisentraut wrote:
> > Vincent Predoehl wrote:
> >> I was running fink and it said to report this:
> >> configure: WARNING: krb5.h: present but cannot be compiled
>
On Friday 26 December 2008 01:12:26 Tom Lane wrote:
> More generally, there are a *whole lot* of ridiculous inefficiencies
> in our information_schema views; I'm surprised there haven't been
> more complaints about them. Sometime someone ought to go through
> the whole set and see what other refac
Vincent Predoehl wrote:
On Dec 20, 2008, at 9:15 AM, Peter Eisentraut wrote:
On Saturday 20 December 2008 02:15:05 Vincent Predoehl wrote:
On Dec 19, 2008, at 3:48 AM, Peter Eisentraut wrote:
Vincent Predoehl wrote:
I was running fink and it said to report this:
configure: WARNING: krb5.h
Vincent Predoehl wrote:
This is not the config.log file from the run that produced the warning
you are complaining about.
I did run configure several times since the error. I know nothing of
autoconf and didn't know to save the config.log file. I just ran
./configure again for 8.3.5 and did
On Tuesday 30 December 2008 17:49:16 Richard Evans wrote:
> I've taken a look at the current development snapshot ane made a new
> patch. This is against the snapshot source dated 2008-12-30.
Half of this patch appears to attempt to fix not cross-compilation problems,
but out-of-tree builds (vpa
Richard Evans wrote:
I've taken a look at the current development snapshot ane made a new
patch. This is against the snapshot source dated 2008-12-30.
This is now committed.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgr
On Tuesday 06 January 2009 02:03:14 Tom Lane wrote:
> I don't think there's a bug here, at least not in the sense that it
> isn't Operating As Designed. But it does seem like we could do with
> some more/better documentation about exactly how FOR UPDATE works.
> The sequence of operations is evide
On Thursday 22 January 2009 15:39:00 Sergey Burladyan wrote:
> seb=# select xpath('/русский/text()', v::xml) from (select
> xml('<русский>язык')) as x(v);
> ERROR: could not parse XML data
> DETAIL: Entity: line 1: parser error : Input is not proper UTF-8, indicate
> encoding !
> Bytes: 0xF0 0xF3
Mykola Stryebkov wrote:
Hi,
# psql83 template1
Password:
Welcome to psql83 8.3.5, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
Heikki Linnakangas wrote:
xuan--2009.03--submitbug--support--postgresql@baldauf.org wrote:
When executing
"ALTER TABLE sometable ALTER COLUMN somecolumn TYPE VARCHAR(7)", the
whole
table is re-written, and this rewrite takes many hours. During these
hours,
all writers on this table stall,
vikas wrote:
The following bug has been logged online:
Bug reference: 4690
Logged by: vikas
Email address: vikas.du...@newgen.co.in
PostgreSQL version: PostgreSQL 7.3
Time to upgrade.
Operating system: i686-pc-linux-gnu
Description:an select query is not using th
On Monday 30 March 2009 17:34:36 Martin Pitt wrote:
> recently, I started to get quite a bunch of bug reports a la
> "PostgreSQL fails to start due to too little shared memory" [1]. I
> have never seen this before, neither in Debian, so I guess the
> SHMMAX defaults changed somewhat in Linux 2.6.27
On Sunday 05 April 2009 13:44:37 Stefano Salvador wrote:
>select sin(pi());
>
> returns: 1.2246
>
> or:
>
>select cos(pi()/2);
>
> returns: 6.123
>
> but sin and cos are limited between -1 and 1 !!!
I get
=> select sin(pi());
sin
--
1.22460635382238e-16
(1 ro
On Friday 10 April 2009 08:39:33 Martin Pitt wrote:
> Tom Lane [2009-04-10 1:15 -0400]:
> > Martin Pitt writesyuqhom#3:
> > > The test suite detected one regression in libpq, though: Setting
> > > $PGHOST now complains about a missing root.crt, although this is only
> > > relevant on the server s
On Friday 10 April 2009 17:13:55 Martin Pitt wrote:
> However, we can't afford to break existing installations. If a user
> has 8.4 installed locally, he'll use libpq from 8.4, and suddenly he
> could not connect to a remote SSL 8.3 cluster any more. So the check
> needs at least be turned into a w
On Friday 10 April 2009 21:27:54 Stephen Frost wrote:
> I agree with this. Avoiding spoofing is good, but so is on the wire
> encryption even if you don't have anti-spoofing. This is a reasonable
> set-up and we shouldn't just fail on it.
This whole debate hinges on the argument that encryption
On Friday 10 April 2009 21:32:29 Stephen Frost wrote:
> A properly configured server could cause a failure too unless the client
> is *also* properly configured. Sure, it's good for people to do. No, I
> don't think we should break things if people don't build out a whole PKI
> for PG and configu
On Friday 10 April 2009 22:44:44 Bruce Momjian wrote:
> The problem is that libpq doesn't have any ability to warn/prompt like
> SSH and web browsers do, so I think Magnus patterned the libpq behavior
> around cases where warning/prompt failed in these environments.
>
> I am not saying the current
On Friday 10 April 2009 21:32:29 Stephen Frost wrote:
> Uh, no, the right fix is to have a warning/prompt (as pretty much all
> web browsers today do) but then continue to connect.
On that matter, it is interesting to observe where web browsers are heading
today.
It used to be that web browsers
On Friday 10 April 2009 22:50:02 Tom Lane wrote:
> Peter Eisentraut writes:
> > On Friday 10 April 2009 21:27:54 Stephen Frost wrote:
> >> I agree with this. Avoiding spoofing is good, but so is on the wire
> >> encryption even if you don't have anti-spoofing.
On Sunday 12 April 2009 01:58:26 Magnus Hagander wrote:
> "sslmode=prefer" honestly makes no sense - if I don't care if it ends up
> encrypted or not (which it means), then why not just run with SSL off
> and not have to deal with the overhead?
Perhaps a large part of the problem at hand is in fac
On Sunday 12 April 2009 12:52:53 Magnus Hagander wrote:
> This is a different way to do bruces suggestion of a different
> default. That's possibly even clearer. So I can definitely go with
> this, but I think two different parameters makes it more clear and is
> better.
I think altogether c
On Tuesday 14 April 2009 17:05:45 Martin Pitt wrote:
> Of course I assumed that the server and client are on different
> systems. If they are on the same, then we just use the Unix socket and
> don't need all this SSL fuss at all.
That's what you think. Just read the hackers thread about SSL over
On Monday 20 April 2009 11:19:04 Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> On 14 apr 2009, at 04.33, Bruce Momjian wrote:
> >>> Magnus Hagander wrote:
> > I would actually call the two parameters 'verify-cert' and 'verify-
> > cn',
> > and document t
On Tuesday 21 April 2009 14:04:01 fduerr wrote:
> CREATE OR REPLACE FUNCTION eq_int_bool(INTEGER, BOOLEAN) RETURNS BOOLEAN AS
> 'SELECT CAST($1 AS BOOLEAN)=$2;' LANGUAGE SQL IMMUTABLE;
> CREATE OPERATOR = (
> LEFTARG=INTEGER,
> RIGHTARG=BOOLEAN,
> PROCEDURE=eq_int_bool,
> COMMUTATOR= = ,
> NE
On Friday 15 May 2009 01:07:11 Hershel Fisch wrote:
> Hi, I realized that sorting date is done like text and not numeric (dates)
> e.g. SELELCT * FROM database_name ORDER BY date ASC
>
> Return order
>
> 3/02/09
> 4/19/09
> 4/2/09
>
> Thanks,
This report would make a lot more sense if you posted
On Thursday 21 May 2009 10:52:33 Целуйко Дмитрий wrote:
> When DDL triggers will be supported by PostgreSQL?
There are currently no concrete plans for that, but if someone comes up with a
good design and implementation, it could be acceptable. But don't hold your
breath.
--
Sent via pgsql-bug
On Thursday 28 May 2009 13:31:16 Itagaki Takahiro wrote:
> Here is a patch to fix the bug. I added a parameter 'encode' to
> map_sql_value_to_xml_value() and pass false for xml attributes.
I have committed your patch with minor editing. Thanks.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
On Sunday 31 May 2009 20:00:44 Tom Lane wrote:
> Itagaki Takahiro writes:
> > Here is a patch to fix the bug. I added a parameter 'encode' to
> > map_sql_value_to_xml_value() and pass false for xml attributes.
>
> One thing I was wondering about, which is sort of highlighted by your
> patch, is wh
On Wednesday 10 June 2009 18:02:45 Dhaval Jaiswal wrote:
> Yes, there isn't a use case for a month value outside 1-12, i found this
> due a typo.
What Would Oracle Do?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
On Wednesday 24 June 2009 04:59:05 Jim Michaels wrote:
> If you are looking for hash collision protection, start looking at SHA-256
> or SHA-512.
Well, are we looking for that? We are not using MD5 for digital signatures.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
On Friday 26 June 2009 00:04:02 Alfred Monticello wrote:
> in doc/Makefile, tar is run to extract an archive with xf options. Needs
> oxf to map to owner of person running tar, otherwise Invalid Argument
> occurs and the Makefile errors out.
>
> A better solution might be to compact postgres as UID
On Saturday 27 June 2009 15:06:30 Ricardo wrote:
> Need support for acent sensitive in UTF-8, in clause like SQL.
This is not a bug. But you may find this helpful:
http://wiki.postgresql.org/wiki/Strip_accents_from_strings
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
On Thursday 02 July 2009 02:45:24 John R Pierce wrote:
> ajmcello wrote:
> > The only downside with adding o to tar that I can see is if it isn't
> > supported by a non-GNU version of tar.
>
> On solaris 9 and 10 at least, tar -o means set ownership of extracted
> files to the runner and not the ui
On Thursday 02 July 2009 09:56:35 Peter Eisentraut wrote:
> On Thursday 02 July 2009 02:45:24 John R Pierce wrote:
> > ajmcello wrote:
> > > The only downside with adding o to tar that I can see is if it isn't
> > > supported by a non-GNU version of tar.
> >
On Monday 13 July 2009 19:17:49 David Kerr wrote:
> We're using SLES 11, and uuid-ossp isn't delivered in the
> postgresql-contrib package, we opened a case with Novell and this was their
> reply:
> [some nonsense]
I'm sorry to say that SUSE just isn't a good source if you want to do serious
Post
On Friday 17 July 2009 11:12:41 Jan-Ivar Mellingen wrote:
> One of our customers discovered that by replacing <>TRUE with =FALSE in
> a query of a table containing 750.000 records reduced the query time
> from about 12 seconds to about 60 milliseconds!
> This is a dramatical difference, but I cann
On Friday 17 July 2009 12:45:47 Mikael Krantz wrote:
> It might be that your column may be NULL as well as TRUE or FALSE. I
> am no expert in this matter though.
Nulls also need to be considered when attempting to substitute purportedly
equivalent clauses. But in this case it wouldn't actually m
On Wednesday 29 July 2009 01:57:50 Jim Michaels wrote:
> it is impossible to compile in libpq headers unless the installation
> directory for postgres has no spaces. compilers such as gcc/mingw don't
> like that.
Proof please?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To m
On Wednesday 29 July 2009 11:39:03 Giorgio Valoti wrote:
> I get a crash when I invoke xml function like xml_is_well_formed.
>
> It works with static xml but not if it’s dynamically generated.
>
> It crashes even if I first create the xml dynamically and then invoke the
> function with static text.
On Monday 10 August 2009 03:41:06 Richard Neill wrote:
> * Division of a timestamp by an interval should result in something
> dimensionless.
What would be the semantics of this? What's today divided by 2 hours?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to
On Friday 14 August 2009 02:32:38 Jim Michaels wrote:
> The following bug has been logged online:
>
> Bug reference: 4985
> Logged by: Jim Michaels
> Email address: jmich...@yahoo.com
> PostgreSQL version: 8.4.0
> Operating system: XP Pro Sp3
> Description:LIMIT documen
On tor, 2009-08-20 at 20:24 +, Brian Ceccarelli wrote:
> since the < and > comparison operators seem to be case insensitive:
>
> select 'a' < 'Z';-- true
> select 'a' < 'z';-- true
> select 'A' < 'Z';-- true
> select 'A' < 'z';-- true
>
> select 'z' < 'A';-- false
> select
On mån, 2009-08-24 at 20:10 +0100, Greg Stark wrote:
> It's completely email based so we could just treat it as a mailing
> list without having to go visit a web interface to stay up to date. We
> could add CVS/whatever hooks so whenever a commit message says it
> closes a bug it gets closed automa
On mån, 2009-08-24 at 23:07 +0100, Greg Stark wrote:
> I think it's a conceit to think we always fix bugs immediately.
I completely agree with that one. The claim that we don't need a bug
tracker because most bugs get fixed immediately is bogus because a) it's
not true, and b) it doesn't help peo
On mån, 2009-08-24 at 19:56 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Personally I still think debbugs would suit us perfectly, but 1. I don't
> > have time to handle it, 2. nobody else believes this, 3. the debbugs
> > developers are not very interested in helping us use it.
>
> What i
On tor, 2009-09-03 at 20:53 +, Raja Rayaprol wrote:
> I would like to know if there is demand for similar functionality from
> Postgres users, and whether PostgreSQL Plus (or other variant) offer
> any
> relief in this area ?
This doesn't appear to be a bug. You might get better feedback fro
On Sun, 2009-09-20 at 01:00 +, Paulo wrote:
> like to select a field containing Numeric 4 and compared with a
> char(30)
> field.
> In oracle and postgresql to version 8.2 worked perfectly, now the new
> version no longer works, as we have many queries in this format.
Hard to say without havi
On Fri, 2009-10-02 at 02:17 +, Dan French wrote:
> #1: bytea_string = '"0"' (table; bytea)
> Function:
>trim('"' both from bytea_string)
> fails and returns: '"0'
Works for me. Please submit a complete test case.
> #2: Come on folks: Bytea is a series of bytes. Conversion to ASCII is
On Fri, 2009-10-09 at 07:51 +, Mohamed Altamimi wrote:
> I am new in Postgres .How i can give relationship between two tables 1 to
> many. I am using pgAdmin III.
This is not a bug. There are other forums for user support.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
On Mon, 2009-10-12 at 20:42 -0400, Turner, Ian wrote:
> --- postgresql-8.4-8.4.1/src/backend/libpq/auth.c 2009-06-25
> 12:30:08.0 +0100
> +++ postgresql-8.4-8.4.1-fixed/src/backend/libpq/auth.c 2009-09-15
> 20:27:01.0 +0100
> @@ -166,6 +166,8 @@
> #endif
>
> static int
On Mon, 2009-10-19 at 11:05 +, Roman Kapusta wrote:
> I have table with bytea column, which is indexed (1)
> I want to use index during pattern matching (eg. dir like
> someDirectoryName
> || '/%'), but concatenation of two strings cause error (2)
> So I have to use function convert_to (convert
On lör, 2009-10-24 at 14:01 +, Timothy Madden wrote:
> Can the string literal syntax for CREATE FUNCTION please, please be dropped
> ... ?
>
> http://www.postgresql.org/docs/8.4/interactive/plpgsql-structure.html
>
> It is not ANSI/ISO and so annoying for compatibility.
Whatever is inside th
On sön, 2009-10-25 at 13:52 +, Peter Bengtson wrote:
> It would be good if you to the page describing how a db dump is required
> only for major verson upgrades, e.g. from 8.3.x to 8.4.x but not from, say,
> 8.3.7 to 8.3.8, could add a proviso: a DB dump *is* necessary when upgrading
> from a s
On fre, 2009-11-06 at 17:29 +, Jason wrote:
> When I have a plpythonu function returning a composite type that has an
> array column, the function does not work when I try to return a list for
> that column.
There is a patch proposed to address that in 8.5, but before that,
arrays are pretty m
On Sun, 2009-11-08 at 16:33 -0500, Robert Haas wrote:
> On Sat, Nov 7, 2009 at 5:23 AM, Peter Eisentraut wrote:
> > On fre, 2009-11-06 at 17:29 +, Jason wrote:
> >> When I have a plpythonu function returning a composite type that has an
> >> array column, the functi
On tis, 2009-11-10 at 20:45 +, Boh Yap wrote:
> make check
> failed, when trying to initdb, with this message in log:
>
> could not determine encoding for locale "en_AU.US-ASCII": codeset is
> "US-ASCII"
Try using a different locale.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@
On tis, 2009-11-10 at 17:15 -0500, Tom Lane wrote:
> I was wondering what we ought to do about this. I can't find any clear
> documentation about these locales on my Mac, but it sure looks like they
> are effectively encoding-agnostic, which means that it might be
> reasonable to default to SQL_AS
On ons, 2009-11-11 at 14:27 -0500, Tom Lane wrote:
> Okay. Then we need to fix pg_get_encoding_from_locale to distinguish
> "I don't know the locale's encoding" from "I know the encoding and
> it's
> SQL_ASCII". I'm inclined to make it return -1 for the former,
Makes sense.
The other alternativ
On lör, 2009-11-07 at 12:23 +0200, Peter Eisentraut wrote:
> On fre, 2009-11-06 at 17:29 +, Jason wrote:
> > When I have a plpythonu function returning a composite type that has an
> > array column, the function does not work when I try to return a list for
> > that co
On ons, 2009-09-23 at 20:31 -0300, Euler Taveira de Oliveira wrote:
> Marek Lewczuk escreveu:
> > Please execute following example:
> > select * from ts_debug('english', ' > align="right" style="margin: 0px 0px 5px 5px;" test_aa="26461"/>')
> >
> > As the result you will see, that is not identifi
On mån, 2009-11-16 at 10:19 +0100, Pavel Stehule wrote:
> wrong:
>
> pa...@nemesis ~]$ psql postgres -v x=10 -c "select :x"
> ERROR: syntax error at or near ":"
> LINE 1: select :x
>^
This is documented in the psql man page.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@pos
On mån, 2009-11-16 at 12:28 +0100, Pavel Stehule wrote:
> 2009/11/16 Peter Eisentraut :
> > On mån, 2009-11-16 at 10:19 +0100, Pavel Stehule wrote:
> >> wrong:
> >>
> >> pa...@nemesis ~]$ psql postgres -v x=10 -c "select :x"
> >> ERR
On tor, 2009-11-26 at 22:59 -0500, Robert Haas wrote:
> ISTM that if you run psql with "-f -", you shouldn't expect to get an
> interactive shell. Rather, you should expect psql to do whatever it
> normally does when given -f somefilename, except using stdin rather
> than the file. After all, you
On tor, 2009-12-03 at 14:46 -0800, David Gardner wrote:
> Not sure about the try block being related, I included it in my
> example mostly because the example is a simplified version of some
> code I was working on that had a try/except block.
> I tried the function without the try block and it ra
On tor, 2009-12-03 at 19:02 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > ... So you should not try to assign to
> > the parameters of a function.
>
> If it's allowed in normal Python functions, that definitely needs to be
> documented. Better would be to fi
On mån, 2010-01-04 at 03:48 +, Ben Woosley wrote:
> However, unique and foreign key constraints added using the "alter
> table add
> constraint" syntax fail on the column name. At this point the
> statement has
> enough information (the host table name) to properly identify the
> column
> desp
1 - 100 of 657 matches
Mail list logo
