> Just updated...
> peter=# SELECT EXTRACT(DOW FROM TIMESTAMP '2001-02-16 20:38:40');
> ERROR: Timestamp with time zone units 'dow' not recognized
> This is documented to work.
Ah, I broke this with some recent additions to implement more ISO
conventions (I changed the behavior of the date/time
> Plus or minus?
Is there a standard for this? We are printing date/time using Posix
conventions, which are opposite from the SQL conventions for setting
time zone (which we don't yet support, since it is fundamentally useless
;) I apparently implemented one, and you expect the other.
> peter=#
HI
I have to setup PERL to interact with PGSQL.
I have taken the following steps.
1.Installation of perl_5.6.0 under Redhat Linux 7.0
2.Installation of POSTGRESQL under Redhat Linux7.0
Both are working perfectly as seperate modules.
Now I need to
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> In my understanding below row value constructors(I hope this term is
> correct) exaples should return true, but PostgreSQL does not.
By my reading, a "row value constructor" is one of the things in
parentheses, while the whole clause is a "comparison pre
>Chris Bitmead <[EMAIL PROTECTED]> writes:
>> ... I don't
>> like the old large object implementation, I need to store very large
>> numbers of objects and unless this implementation has changed
>> in recent times it won't cut it.
>
>Have you looked at 7.1? AFAIK it has no particular probl
"Serge Sozonoff" <[EMAIL PROTECTED]> writes:
>> I have attached a patch, not sure who wrote this patch, but it seems
>> to work for me!
>> I am asuming that the author has submitted it to the pgsql team, but
>> if not here it is.
It has not been submitted, and it certainly won't get accepted as-i
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Well, the conversion to/from UTF-8 for ISO 8859-10 or later is pretty
> easy and should be supported, I think. Actually I already have
> generated mapping tables for these charsets. I will make patches
> against current and leave it for the core's decisio
steve <[EMAIL PROTECTED]> writes:
> When trying to pg_dump on 7.1.2 (& 7.1.3) I get the following error
> message:
> bash-2.04$ pg_dump dwh
> getTables(): SELECT (for PRIMARY KEY NAME) failed for table nlcdmp.
> Explanation from backend: ERROR: dtoi4: integer out of range
> Several of my tables
Chris Bitmead <[EMAIL PROTECTED]> writes:
> ... I don't
> like the old large object implementation, I need to store very large
> numbers of objects and unless this implementation has changed
> in recent times it won't cut it.
Have you looked at 7.1? AFAIK it has no particular problem with
lots o
> e.g. when I tried to use "recode", which does recognise iso-8859-15
> and 16, and convert to MULE, whatever I do, I obtain "EUR" for the
> euro sign, OE, oe, s, S, z, Z, "Y for the different characters which
> are specific to 15 for example, and that's even worse for 16.
Apparently MULE curren
> > ISO-8859-15 and 16! I don't know anything beyond ISO-8859-10. Can you
> > give me any pointer (URL) explaining what they are?
>
> http://www.evertype.com/sc2wg3.html
>
> It links to files describing iso-8859-14 to 16.
[snip]
Thanks for the info.
> Well, for the history iso-10646 was 32 bit
On 10 Oct 2001 at 17:12 (-0400), Bruce Momjian wrote:
|
| Our FAQ, item 4.16.2 has:
|
| $newSerialID = nextval('person_id_seq');
| INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
|
| Is this correct Perl? I don't see a nextval() function in Perl. Can
| you ca
Our FAQ, item 4.16.2 has:
$newSerialID = nextval('person_id_seq');
INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
Is this correct Perl? I don't see a nextval() function in Perl. Can
you call SQL server-side functions natively from Perl?
--
Bruce Momj
On Monday 08 October 2001 09:37 pm, John Summerfield wrote:
> I don't see for whom the long name would be a problem; certainly if
> it has been that way for five years, it couldn't have been a serious
> problem.
Ask Marc why he changed it.
> > > > Correction: Marc Fournier controls the entire di
Hi,
As said in another mail, I have tried to add iso-8859-15 (Latin 9) &
iso-8859-16 (Latin 10) to PostgreSQL, I think I have done mostly all
that's necessary. But I miss two things :
- latin92mic/mic2latin9/latin102mic/mic2latin10 in conv.c
- the leading character value in pg_wchar.h
I don't k
Tom, Bruce, any suggestions?
[EMAIL PROTECTED] (Ryan) wrote in message
news:<[EMAIL PROTECTED]>...
> I changed the number of shared buffers to 3000 and my database locks
> on a simple query. I must kill the database with pg_ctl stop -m i.
> Neither "smart" nor "fast" stops appear to succeed.
Hello,
In dump file statement which grants permissions on view exists before
statement which create view.
For tables and sequences permissions dumped in correct order.
--TOC Entry ID 124 (OID 150248)
GRANT ALL on my_view to group sales;
... skipped
--TOC Entry ID 123 (OID 194103)
CREATE VIEW m
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 08 October 2001 15:13
> To: Dave Page
> Cc: 'Jean-Michel POURE'; [EMAIL PROTECTED]; Bruce
> Momjian; [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [HACKERS] What about CREATE OR
> REPLACE FUNC TION?
>
>
>
> Hi,
>
> It apears that getting Postgres and OSX 10.1 to work is not just a
> case of some compiler flags.
>
> I have attached a patch, not sure who wrote this patch, but it seems
> to work for me!
>
> I am asuming that the author has submitted it to the pgsql team, but
> if not here it is.
>
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 08 October 2001 14:43
> To: [EMAIL PROTECTED]
> Cc: Tom Lane; Bruce Momjian; [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [HACKERS] What about CREATE OR
> REPLACE FUNCTION?
>
>
> Dear all,
>
> 1
Of course, in 7.1 foreign key constraints become rather confused when
you rename columns on them.
create table parent (id serial);
create table child (id int4 references parent(id) on update cascade);
alter table parent rename column id to anotherid;
alter table child rename column id to junk;
in
Hi,
I need to use some Chinese characters in charset MS950(CP950) but
not in Big5. Big5 and MS950 encoding are very much similiar but
currently there is no support for MS950 and I will need to add it.
I've read files in src/backend/utils/mb directory but still not
sure what files to modify. Or c
On Fri, 05 Oct 2001 19:35:48 -, Thomas Lockhart wrote:
> ...
>
> Have you actually used ANSI SQL9x time zones? istm that "one offset fits
> all" is really ineffective in supporting real applications, but I'd like
> to hear about how other folks use it.
Fortunately, most of our date/time in
I've been looking a bit at the MULE encoding wrt to latin 9 and 10. It
seems that there is no support for the Euro at all in it.
e.g. when I tried to use "recode", which does recognise iso-8859-15
and 16, and convert to MULE, whatever I do, I obtain "EUR" for the
euro sign, OE, oe, s, S, z, Z, "Y
* Tatsuo Ishii <[EMAIL PROTECTED]> [011010 18:21]:
> Receiving a request to add ISO 8859-15 and 16, I review the multibyte
> support code and found several errors in it.
>
> 1) There is a confusion between "LATIN5" and ISO 8859-5. LATIN5 is not
>ISO 8859-5, but is actually ISO 8859-9. Should
* Tatsuo Ishii <[EMAIL PROTECTED]> [011010 18:20]:
> > As said in another mail, I have tried to add iso-8859-15 (Latin 9) &
> > iso-8859-16 (Latin 10) to PostgreSQL, I think I have done mostly all
> > that's necessary. But I miss two things :
>
> ISO-8859-15 and 16! I don't know anything beyond I
peter=# select current_timestamp;
timestamptz
---
2001-10-10 01:04:54.965162+02
(1 row)
peter=# select extract(timezone_hour from current_timestamp);
date_part
---
-2
(1 row)
Plus or minus?
peter=# select extract(timezone_hour from timesta
Tatsuo Ishii writes:
> BTW, should we support ISO 8859-6 and beyond for 7.2?
If possible we should. Otherwise people might spread the word that
PostgreSQL is not ready for the Euro.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end o
Apologies for posting to [Hackers], have already posted to [Patches]
with no reply.
When trying to pg_dump on 7.1.2 (& 7.1.3) I get the following error
message:
bash-2.04$ pg_dump dwh
getTables(): SELECT (for PRIMARY KEY NAME) failed for table nlcdmp.
Explanation from backend: ERROR: dtoi4: int
We use timestamps and intervals quite a bit in our applications. We
also use several different databases. Unfortunately, the time/date/
interval area is one that is not at all consistent between databases.
It makes life particularly difficult when trying to re-use application
code.
So far, as c
okay, daily snapshots are now being generated on the new server ... right
now, all the mirror sites are stale while Vince does some finishing
touches on the mirroring scripts/cgi's ... once he gerts that done, then,
from my perspective, we'll be ready for beta ...
On Mon, 8 Oct 2001, Tom Lane w
Rod Taylor wrote:
> It should be noted that there is still a limit of about 1GB if I
> remember correctly.
You're right, there is still a practical limit on the size of
a text field. And it's usually much lower than 1GB.
The problem is that first, the (encoded) data has to be put
You need to change the pg_hba.conf file in your PostgreSQL
installation so that "password" authentication is used. Check out:
http://www.postgresql.org/idocs/index.php?client-authentication.html
for details.
Hope that helps,
Mike Mascari
[EMAIL PROTECTED]
> Balaji Venkatesan wrote:
>
> Hi L
Hi List,
Iam pretty new to this list as well as PostgreSQL.
I hope to find some crucial info from here.
Thnx in advance to all those who would contribute to it.
Iam basically an Oracle Consultant.
At first i would like to clarify how to enforce password for a user i have
created.
I u
Hi,
I've done some research on your request,
but I could not find very much to help you.
What I've found about
1) Connections
http://www.postgresql.org/idocs/index.php?runtime-config.html
enable LOG_CONNECTIONS (boolean), LOG_PID (boolean)
to log database users
2) Table locks
nothing
3) C
On Wed, Oct 10, 2001 at 03:40:25PM +0900, Tatsuo Ishii wrote:
> Receiving a request to add ISO 8859-15 and 16, I review the multibyte
> support code and found several errors in it.
>
> 1) There is a confusion between "LATIN5" and ISO 8859-5. LATIN5 is not
>ISO 8859-5, but is actually ISO 8859
36 matches
Mail list logo
