Which ones belong to the backend and which ones to the frontend?
Or even more: which ones belong to the backend, which ones
to the frontend #1, which ones to the frontend #2, etc...
For examle, I have two fronends:
FE1: UNICODE, WIN1251
FE2: KOI8, UNICODE
BE: UNICODE, LATIN1, ALT
I posted this in my last message, but have not heard anything yet so I'm
wondering if it was overlooked. I need to know how to change a column from
being say a varchar(9) to an integer. Does anyone know how to change the
data type?
Geoff
---(end of
On Mon, Sep 24, 2001 at 10:22:28AM -0400, Marc G. Fournier wrote:
okay, somehow you have two different CVSROOT's configured?
/home/projects/pgsql/cvsroot was the old server, /projects/cvsroot is the
new one
Any hints? I had done a (csh)
cd /usr/src/local/pgsql
find . -name Root -print
Hi all,
while working on a new project involving PostgreSQL and making some
tests, I have come up with the following output from psql :
lang | length | length | text| text
--+++---+---
isl | 7 | 6 | álíta | áleit
isl | 7 | 7 |
Two problems (I've been holding back reporting until I ran into this
second):
Background: I'm trying to migrate an existing db from MS Sql 2K to pgsql by
creating a DTS job.
DB system info: NT 4 sp6a, MS SQL2K Regular, Pgsql ODBC driver 7.01.00.06.
First problem: The ODBC driver reports a
So, this shows two problems :
- length() on the server side doesn't handle correctly Unicode [I have
the same result with char_length()], and returns the number of chars
(as it is however advertised to do), rather the length of the
string.
This is a known limitation.
- the psql
I see following in src/backend/optimizer/plan/planner.c
if (child IsA(child, FromExpr))
{
/*
* Yes, so do we want to merge it into parent? Always do
* so if child has just one element (since that doesn't
* make
Has anyone successfully built docs recently? I got:
cd sgml /bin/tar -c -f ../admin.tar -T HTML.manifest *.gif *.css
/bin/tar: *.gif: Cannot stat: No such file or directory
--
Tatsuo Ishii
---(end of broadcast)---
TIP 2: you can get off all lists
Gowey, Geoffrey wrote:
This is not for -hackers.
How so?
And the answer is no, you can't. Recreate the table with correct types
and insert the old values into it.
You're kidding me, right? *prepares to gargle* MS Sql server can. Surely
we can implement this feature or aren't we
Hi Gowey,
Please post to pgsql-odbc list if the problem is ODBC
specific.
"Gowey, Geoffrey" wrote:
Two problems (I've been holding back reporting until I ran into this
second):
Background: I'm trying to migrate an existing db from MS Sql 2K to pgsql by
creating a DTS job.
DB system
On Mon, 24 Sep 2001, mlw wrote:
To be honest I am very surprised that MS SQL supports that, but then
again Microsoft is so used to doing everything so utterly wrong, they
have to design all their products with the ability to support
fundamental design error corrections on the fly.
I would
On Mon, 24 Sep 2001, Rod Taylor wrote:
Out of curiosity how was option a) implemented? I could envision
supporting multiple versions of a tuple style to be found within a
table (each described in pg_attribute). Gradually these would be
upgraded through normal use.
Check the archives (look
This is not for -hackers.
And the answer is no, you can't. Recreate the table with correct types
and insert the old values into it.
On Mon, 24 Sep 2001, Gowey, Geoffrey wrote:
I posted this in my last message, but have not heard anything yet so I'm
wondering if it was overlooked. I need to
This is not for -hackers.
How so?
And the answer is no, you can't. Recreate the table with correct types
and insert the old values into it.
You're kidding me, right? *prepares to gargle* MS Sql server can. Surely
we can implement this feature or aren't we aiming to go head to head with
One thought did just occur to me. It is at least theoretically possible to
simplisticly migrate on column type to another by reading in the data and
oid of the row into a struct, drop the column, create a new column with the
correct data type, and populate. This is ugly, but it is better than
[moved to hackers]
On Mon, 24 Sep 2001, Stephan Szabo wrote:
Postgres should understand that left outer join does not constrict join
order...
But it can. If your condition was a joining between the other table
and the right side of the left outer join, you'd have the same condition
as
On Mon, 24 Sep 2001, Patrick Welche wrote:
On Sat, Sep 22, 2001 at 08:15:11PM -0500, Dominic J. Eidson wrote:
On Sat, 22 Sep 2001, Marc G. Fournier wrote:
anoncvs: :pserer:[EMAIL PROTECTED]:/projects/cvsroot
- passwd is blank, but postgresql should work just as well
I can
On Sat, Sep 22, 2001 at 08:15:11PM -0500, Dominic J. Eidson wrote:
On Sat, 22 Sep 2001, Marc G. Fournier wrote:
anoncvs: :pserer:[EMAIL PROTECTED]:/projects/cvsroot
- passwd is blank, but postgresql should work just as well
I can confirm that this works.
Still no good for me:
Gowey, Geoffrey wrote:
I posted this in my last message, but have not heard anything yet so I'm
wondering if it was overlooked. I need to know how to change a column from
being say a varchar(9) to an integer. Does anyone know how to change the
data type?
create temptable
as select
Gowey, Geoffrey wrote:
One thought did just occur to me. It is at least theoretically possible to
simplisticly migrate on column type to another by reading in the data and
oid of the row into a struct, drop the column, create a new column with the
correct data type, and populate. This is
Does this mean that the code is or isn't usable?
Geoff
-Original Message-
From: Hiroshi Inoue [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 23, 2001 11:02 PM
To: Stephan Szabo
Cc: Gowey, Geoffrey; [EMAIL PROTECTED]
Subject: Re: [HACKERS] an already existing alter table drop column
Marc G. Fournier writes:
with all the changes going on, we're most likely looking at Oct 1st,
earliest ... things are startin to stabilize, but until that 18gig is
installed next week, we still have th eproblems with updating ftp, unless
Peter can clear out th e400+Meg in his acount? :)
Uh,
isn't
On Mon, 24 Sep 2001, Gowey, Geoffrey wrote:
Does this mean that the code is or isn't usable?
Geoff
-Original Message-
From: Hiroshi Inoue [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 23, 2001 11:02 PM
To: Stephan Szabo
Cc: Gowey, Geoffrey; [EMAIL PROTECTED]
damn. Is there a usable version being worked around? If so, how long before
it is available?
Geoff
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 24, 2001 1:14 PM
To: Gowey, Geoffrey
Cc: 'Hiroshi Inoue'; Stephan Szabo; [EMAIL PROTECTED]
On Mon, 24 Sep 2001, Gowey, Geoffrey wrote:
damn. Is there a usable version being worked around? If so, how long before
it is available?
too many dissending opinions on how it should (and shouldn't) be done ...
the one that was put in pre-maturely needed 2x the disk space to do ... so
if you
I do like the flag idea as a temporary patch until a fully workable solution
is available. Just run a delete on the column and then flag it so it takes
up no space and is hidden. By doing this now a more perfect solution can be
found later.
Geoff
-Original Message-
From: Marc G.
Also, rename the column to something else so a new one can be created in
it's place with the same name. Do columns have their own oid's? If so this
plus some random chars could be the new name.
Geoff
-Original Message-
From: Gowey, Geoffrey
Sent: Monday, September 24, 2001 1:35 PM
Alex Pilosov [EMAIL PROTECTED] writes:
I'm going to CC this to -hackers, maybe someone will shed a light on the
internals of this.
It's not unintentional. See
http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/explicit-joins.html
regards, tom lane
-- Hi Kevin, and everyone!
--
-- I don't think that I only found a minor bug compared to
-- the other you wrote in your last letter: the backend crash
-- is caused by the same CHECK constraint in the child table.
--
-- However, for you without time to analyzing Kevin's huge
-- scheme, here is
Kovacs Baldvin wrote:
Hi everybody!
I tried, and it works: the current CVS version really runs
happily the query what sent to heaven our 7.1 version of the
backend.
Kevin: your original complex schema also runs smoothly.
Thanks for our mindful developers!
Regards,
Baldvin
I think
On Mon, 24 Sep 2001, Alex Pilosov wrote:
On Sun, 23 Sep 2001, Stephan Szabo wrote:
On Sun, 23 Sep 2001, Alex Pilosov wrote:
Postgres treats join syntax as an explicit definition of what order to
joins in. So, I'd guess it sees the first as: do the LOJ and then join
that to the
What version are you trying this script on? I'm not
seeing a crash on my 7.2 devel system (and the update occurs).
On Mon, 24 Sep 2001, Kovacs Baldvin wrote:
-- Hi Kevin, and everyone!
--
-- I don't think that I only found a minor bug compared to
-- the other you wrote in your last
Hi everybody!
I tried, and it works: the current CVS version really runs
happily the query what sent to heaven our 7.1 version of the
backend.
Kevin: your original complex schema also runs smoothly.
Thanks for our mindful developers!
Regards,
Baldvin
I think Jan wrote:
Sorry, I missed
33 matches
Mail list logo
