Re: [HACKERS] error during vacuum full

Am Mittwoch, 10. Juli 2002 06:50 schrieb Barry Lind: > Tom, > > No. Restarting the postmaster does not resolve the problem. I am going > to put the debug build in place and see if I can still reproduce. > I've this problem on different machines too (on a daily basis), and restarting the databa

Re: [HACKERS] error during vacuum full

Tom, > Good. I am dead tired and am about to go to bed, but if you can > reproduce with a debuggable build then I would definitely like to > crawl into it tomorrow. Good night. We can pick this up tomorrow. > At this point I do not have the faintest idea what might cause the > problem to go a

Re: [HACKERS] error during vacuum full

Barry Lind <[EMAIL PROTECTED]> writes: > No. Restarting the postmaster does not resolve the problem. Now you've got my attention ;-) ... this is completely at variance with my theories about the cause of the problem. Destruction of a theory is usually a sign of impending advance. > I am going

Re: [HACKERS] error during vacuum full

Tom, No. Restarting the postmaster does not resolve the problem. I am going to put the debug build in place and see if I can still reproduce. --Barry Tom Lane wrote: >Barry Lind <[EMAIL PROTECTED]> writes: > > >>The only postgres processes running are: >> >> > > > >>[root@cvs root]

Re: [HACKERS] error during vacuum full

Barry Lind <[EMAIL PROTECTED]> writes: > The only postgres processes running are: > [root@cvs root]# ps -ef | grep post > postgres 1004 1 0 Jul03 ?00:00:00 > /usr/local/pgsql/bin/postmaster > postgres 1069 1004 0 Jul03 ?00:00:00 postgres: stats buffer > process > postg

Re: [HACKERS] (A) native Windows port

On Wed, 2002-07-10 at 00:09, Lamar Owen wrote: > On Tuesday 09 July 2002 04:17 pm, Hannu Krosing > > It is quite easy to both check for a running postmaster and start/stop > > one. > > Not when there is no ps in your path. Or pg_ctl for that matter. Nor is > there necessarily a /proc tree wai

Re: [HACKERS] error during vacuum full

Tom, I am not sure exactly what you mean by 'open client transactions' but I just killed off all client processes. The only postgres processes running are: [root@cvs root]# ps -ef | grep post postgres 1004 1 0 Jul03 ?00:00:00 /usr/local/pgsql/bin/postmaster postgres 1069 1004

Re: [HACKERS] Proposal: CREATE CONVERSION

On Wed, 10 Jul 2002, Peter Eisentraut wrote: > Sure. However, Tatsuo maintains that the customary Japanese character > sets don't map very well with Unicode. Personally, I believe that this is > an issue that should be fixed, not avoided, but I don't understand the > issues well enough. I hear

Re: [HACKERS] Unintegrated stuff in source tree

On Wed, 10 Jul 2002, jtv wrote: > On Tue, Jul 09, 2002 at 11:20:47PM -0400, Bruce Momjian wrote: > > > > > > Has the author been given CVS access yet? > > > > Yes, he has. I got him in touch with Marc. I was just pointing out > > that while he knows C++, he needs help getting the connecting stu

Re: [HACKERS] error during vacuum full

Barry Lind <[EMAIL PROTECTED]> writes: > It was not compiled with debug. I will do that now and see if this > happens again in the future. If and when it happens again what would > you like me to do? I am willing provide you access if you need it. Well, first off, please confirm that killing

Re: [HACKERS] error during vacuum full

Tom, It was not compiled with debug. I will do that now and see if this happens again in the future. If and when it happens again what would you like me to do? I am willing provide you access if you need it. thanks, --Barry Tom Lane wrote: >Barry Lind <[EMAIL PROTECTED]> writes: > > >>W

Re: [HACKERS] error during vacuum full

Barry Lind <[EMAIL PROTECTED]> writes: > When trying to perform a full vacuum I am getting the following error: > ERROR: No one parent tuple was found Want to dig into it with gdb, or let someone else into your system to do so? I've suspected for awhile that there's still a lurking bug or three

Re: [HACKERS] Unintegrated stuff in source tree

On Tue, Jul 09, 2002 at 11:20:47PM -0400, Bruce Momjian wrote: > > > > Has the author been given CVS access yet? > > Yes, he has. I got him in touch with Marc. I was just pointing out > that while he knows C++, he needs help getting the connecting stuff > merged to our coding style. Haven't h

[HACKERS] error during vacuum full

When trying to perform a full vacuum I am getting the following error: ERROR: No one parent tuple was found Plain vacuum works fine. Thinking it might be a problem with the indexes I have rebuilt them but still get the error. What does this error indicate and what are my options to solve th

Re: [HACKERS] Unintegrated stuff in source tree

On Wed, Jul 10, 2002 at 12:18:16AM +0200, Peter Eisentraut wrote: > There seems to have been an accumulation lately of stuff that was simply > dumped into the source tree without any sort of integration. I am > particularly talking about interfaces/ssl and interfaces/libpqxx. No > doubt both of

Re: [HACKERS] Unintegrated stuff in source tree

Christopher Kings-Lynne wrote: > > > There seems to have been an accumulation lately of stuff that was simply > > > dumped into the source tree without any sort of integration. I am > > > particularly talking about interfaces/ssl and interfaces/libpqxx. No > > > doubt both of these things are us

Re: [HACKERS] Unintegrated stuff in source tree

Neil Conway wrote: > On Tue, Jul 09, 2002 at 11:06:10PM -0400, Bruce Momjian wrote: > > Peter Eisentraut wrote: > > > Personally, I'm uneasy about carrying around another interface library > > > that appears to have no basis in any sort of standard. > > Erm, upon which standards are the other lan

Re: [HACKERS] Unintegrated stuff in source tree

On Tue, Jul 09, 2002 at 11:06:10PM -0400, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Personally, I'm uneasy about carrying around another interface library > > that appears to have no basis in any sort of standard. Erm, upon which standards are the other language interfaces based? > The

Re: [HACKERS] Unintegrated stuff in source tree

> > There seems to have been an accumulation lately of stuff that was simply > > dumped into the source tree without any sort of integration. I am > > particularly talking about interfaces/ssl and interfaces/libpqxx. No > > doubt both of these things are useful in the end, but as they are right

Re: [HACKERS] Unintegrated stuff in source tree

Peter Eisentraut wrote: > There seems to have been an accumulation lately of stuff that was simply > dumped into the source tree without any sort of integration. I am > particularly talking about interfaces/ssl and interfaces/libpqxx. No > doubt both of these things are useful in the end, but as

Re: [HACKERS] pg_access

Hehehe - try FreeBSD for stability over Linux as well :)   Chris -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Nicolas BazinSent: Wednesday, 10 July 2002 9:55 AMTo: Eric Redmond; 'PostGreSQL Hackers'Subject: Re: [HACKERS] pg_access

Re: [HACKERS] pg_access

Just A note on Linux. I consider Linux on the same level as Windows. I have been able to crash it (kernel 2.4.18) just as well and the lib C API is nowhere near complete or fault tolerant to any commercial OS. For the moment nothing beats SCO Openserver/Unixware stability on PC. These are OS

Re: [HACKERS] pg_tables and schemas

> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > > Does the pg_tables view need to be fixed now that we have schemas? > > Yeah, many of the system views need work. I haven't stopped to think > about it yet. If anyone else wants to come up with a proposal, > go for it... Well, just so l

[HACKERS] Postgres Bug Database

Is there a bug tracking system someone online for the postgres engine? I was unable to locate one via the web site. Thanks, James ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Proposal: CREATE CONVERSION

On Wed, 10 Jul 2002 08:21, Peter Eisentraut wrote: > Hannu Krosing writes: ... > > I would even reccommend going a step further and storing all 'national' > > character sets in unicode. > > Sure. However, Tatsuo maintains that the customary Japanese character > sets don't map very well with Unico

Re: [HACKERS] pg_access

Yeah, sure. Whatever.   Eric   -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 09, 2002 7:35 PM To: PostGreSQL Hackers Subject: Re: [HACKERS] pg_access   Dear Eric, Thanks for your input!  I'm still

Re: [HACKERS] pg_access

Dear Eric, Thanks for your input!  I'm still in favor of developing a Windows version of PostGreSQL.  But I don't think that intelligent people are going to want to use any version of Windows (especially since the news of DRMOS and TCPA included in Windows XP and soon to be implemented in

Re: [HACKERS] (A) native Windows port

> Can the ports system take into account the space required for a dumpfile?? :-) It cheats by keeping a backup of the old version -- makes an installable package out of the currently installed version. This is removed once the package has been successfully upgraded (including dependencies). On

Re: [HACKERS] (A) native Windows port

[replying to myself] On Tuesday 09 July 2002 07:34 pm, Lamar Owen wrote: > if you do this. Already RPM can rollback the transaction being done on the > RPM database (it's a db3 database system), but rolling back the filesystem > is a little different. As a note of interest, RPM itself is backed

Re: [HACKERS] (A) native Windows port

On Tuesday 09 July 2002 07:19 pm, Rod Taylor wrote: > On Tue, 2002-07-09 at 19:09, Lamar Owen wrote: > > And what if you have enough disk space to do the dump, but then that > > causes the OS upgrade to abort because there wasn't enough space left to > > finish upgrading (larger packages, perhaps)

Re: [HACKERS] (A) native Windows port

On Tuesday 09 July 2002 06:20 pm, Peter Eisentraut wrote: > The problem in an extensible system such as PostgreSQL is that virtually > every feature change is reflected by a change in the structure of the > system catalogs. It wouldn't be such a terribly big problem in theory to > make the backen

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 19:09, Lamar Owen wrote: > On Tuesday 09 July 2002 04:17 pm, Hannu Krosing wrote: > > On Tue, 2002-07-09 at 22:10, Lamar Owen wrote: > > > The pre-upgrade script is run in an environment that isn't robust enough > > > to handle that. What if you run out of disk space during

Re: [HACKERS] (A) native Windows port

On Tuesday 09 July 2002 04:17 pm, Hannu Krosing wrote: > On Tue, 2002-07-09 at 22:10, Lamar Owen wrote: > > The pre-upgrade script is run in an environment that isn't robust enough > > to handle that. What if you run out of disk space during the dump? > You can either check beforehand or abort a

Re: [HACKERS] pg_access

Ahh and let us not forget that postgresql runs beautifully (so far as I can tell) under Mac OS X, an operating system whose user base demands easy-to-use GUI software. Pgaccess is a different story however-- I haven't gotten it to work yet because tcl/tk is not quite working... Haven't had any t

Re: [HACKERS] Question about syscache

Peter Eisentraut <[EMAIL PROTECTED]> writes: > In syscache.c, the structure cachedesc contains a field reloidattr that is > supposed to contain the number of an attribute that is an OID reference to > another table. But what if there are two such attributes? Specifically, it is a reference to pg

Re: [HACKERS] Proposal: CREATE CONVERSION

Hannu Krosing writes: > Can't we do all collating in unicode and convert charsets A and B to and > >from it ? > > I would even reccommend going a step further and storing all 'national' > character sets in unicode. Sure. However, Tatsuo maintains that the customary Japanese character sets don't

Re: [HACKERS] Proposal: CREATE CONVERSION

Thomas Lockhart writes: > An aside: I was thinking about this some, from the PoV of using our > existing type system to handle this (as you might remember, this is an > inclination I've had for quite a while). I think that most things line > up fairly well to allow this (and having transaction-en

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 22:10, Lamar Owen wrote: > On Tuesday 09 July 2002 01:46 pm, Hannu Krosing wrote: > > On Tue, 2002-07-09 at 18:30, Oliver Elphick wrote: > > > The main problem is getting access to the user data after an upgrade. > > > Can't it be dumped in pre-upgrade script ? > > The pre-

Re: [HACKERS] (A) native Windows port

Oliver Elphick writes: > I never have understood why the basic table structure changes so much > that it can't be read; just what is involved in getting the ability to > read old versions? The problem in an extensible system such as PostgreSQL is that virtually every feature change is reflected

[HACKERS] Unintegrated stuff in source tree

There seems to have been an accumulation lately of stuff that was simply dumped into the source tree without any sort of integration. I am particularly talking about interfaces/ssl and interfaces/libpqxx. No doubt both of these things are useful in the end, but as they are right now they're a he

[HACKERS] Question about syscache

In syscache.c, the structure cachedesc contains a field reloidattr that is supposed to contain the number of an attribute that is an OID reference to another table. But what if there are two such attributes? The concrete case is an index on pg_cast (castsource, casttarget), which both reference

Re: [HACKERS] pg_access

I’m afraid that I don’t hold as much faith as you that Linux will become the “defacto standard” toolset for all website servers. MS, despite its major shortcomings, is fairly slow and steady when it comes to improvements to its OS. That said, Access is crap because no one uses it for what

Re: [HACKERS] bugzilla.pgaccess.org

- Original Message - From: "Jan Wieck" <[EMAIL PROTECTED]> To: "Iavor Raytchev" <[EMAIL PROTECTED]> Cc: "pgaccess - developers" <[EMAIL PROTECTED]>; "pgaccess - users" <[EMAIL PROTECTED]>; "pgsql-hackers" <[EMAIL PROTECTED]>; "pgsql-interfaces" <[EMAIL PROTECTED]> Sent: Tuesday, July 09

Re: [HACKERS] bugzilla.pgaccess.org

Iavor Raytchev wrote: > > Hello, > > As of today, a Bugzilla has been made available at - > > bugzilla.pgaccess.org > > This is a pretty straight forward installation of Bugzilla 2.14.2 > > It is currently empty. There are even no components so the first bug > submissions can be either reques

Re: [HACKERS] pg_access

I'm pleased to see some renewed interest in pg_access.  It seems obvious to me that MS Access is not currently...and probably never will be able to handle data in a robust and reliable fashion.  MS Access' apparent success is due to the user interface quality and "ease of use" for "non-progr

Re: [HACKERS] More fun with BETWEEN

> Seems I have a funny case left (Note the last comparison should be > false): Ugh... I forgot to initialize the result -- so it picked up the previous calls value. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archi

[HACKERS] bugzilla.pgaccess.org

Hello, As of today, a Bugzilla has been made available at - bugzilla.pgaccess.org This is a pretty straight forward installation of Bugzilla 2.14.2 It is currently empty. There are even no components so the first bug submissions can be either request for components or have to wait a few days.

Re: [HACKERS] Proposal: CREATE CONVERSION

On Tue, Jul 09, 2002 at 10:07:11AM +0900, Tatsuo Ishii wrote: > > > Use a simple wrap function. > > > > How knows this function to/from encoding? > > For example you want to define a function for LATIN1 to UNICODE conversion > function would look like: > > function_for_LATIN1_to_UTF-8(from_st

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 13:48, Oliver Elphick wrote: > On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote: > > > Oh, that is a problem. We would have to require the old executables. > > > > Could this be solved with packaging? Meaning can postmasters from old versions > > be packed with a new

Re: [HACKERS] (A) native Windows port

On Tuesday 09 July 2002 01:46 pm, Hannu Krosing wrote: > On Tue, 2002-07-09 at 18:30, Oliver Elphick wrote: > > The main problem is getting access to the user data after an upgrade. > Can't it be dumped in pre-upgrade script ? The pre-upgrade script is run in an environment that isn't robust eno

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 18:30, Oliver Elphick wrote: > On Tue, 2002-07-09 at 18:05, Hannu Krosing wrote: > > The big change was from 6.x to 7.x where a chunk of data moved from end > > of page to start of page and tableoid column was added. Otherways the > > table structure is quite simple. The diff

Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)

On Tue, 2002-07-09 at 17:26, Tom Lane wrote: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > 1) record the lowest uncommitted transaction number (LUTN) , this may > > have problems with wraparound, but I guess they are solvable. Disllow > > VACUUM. Do a CHECKPOINT ('alter database begin backup') >

Re: [HACKERS] DROP COLUMN Progress

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: >> That was my first thought also, but then the wrong attnum would be used >> in the "make_var". Ugh. I think what Chris needs to do is extend the >> eref data structure so that there can be placeholders for dropped >> attributes. Perhaps NU

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 18:05, Hannu Krosing wrote: > The big change was from 6.x to 7.x where a chunk of data moved from end > of page to start of page and tableoid column was added. Otherways the > table structure is quite simple. The difficulties with user _data_ can > be mainly because of binary

[HACKERS] pgaccess update

Hello, This is a short update about the current stage of pgaccess. The development team will try to release 0.98.8 version together with PostgreSQL 7.3 The current areas of active development are - Boyan - the visual schema Chris - reports and forms There are ideas in the area of - Jeff - wi

Re: [HACKERS] Units for storage of internal time zone offsets

> Is there a reason for the restriction to one byte? Offhand I don't > recall that we store TZ offsets on disk at all... Ah, we don't. Sorry I wasn't clear. This is only for the lookup table we use to interpret time zones on *input*. It is contained in src/backend/utils/adt/datetime.c And it ha

Re: [HACKERS] Proposal: CREATE CONVERSION

> An aside: I was thinking about this some, from the PoV of using our > existing type system to handle this (as you might remember, this is an > inclination I've had for quite a while). I think that most things line > up fairly well to allow this (and having transaction-enabled features > may requ

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 17:49, Oliver Elphick wrote: > On Tue, 2002-07-09 at 16:41, Hannu Krosing wrote: > > On Tue, 2002-07-09 at 13:48, Oliver Elphick wrote: > > > On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote: > > > > Example: When PG 7.3 is released, the RPM / deb / setup.exe include th

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 16:41, Hannu Krosing wrote: > On Tue, 2002-07-09 at 13:48, Oliver Elphick wrote: > > On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote: > > > Example: When PG 7.3 is released, the RPM / deb / setup.exe include the > > > postmaster binary for v 7.2 (perhaps two or three

Re: [HACKERS] Units for storage of internal time zone offsets

> Well, sheesh. Let's widen the byte field to int and store all the > offsets in minutes, or even seconds. It doesn't really matter, since the table is used only internally, and only holds current accepted values for time zone offsets. The current scheme works. It might be useful to change the

Re: [HACKERS] [GENERAL] CRC function? (fwd)

FYI, this person wants to hire someone to write a CRC function for PostgreSQL. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.

Re: [HACKERS] (A) native Windows port

On Tuesday 09 July 2002 11:41 am, Hannu Krosing wrote: > The old postmaster should not be built/distributed. As it is for > _upgrading_ only, you just have to _keep_ it when doing an upgrade, not > build a new "old" one ;) Let me reiterate one thing about this. In the midst of a total OS upgrade

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 17:19, Lamar Owen wrote: > On Monday 08 July 2002 03:20 pm, Jan Wieck wrote: > > Another good example: let's add a field to some parsenode struct (was > > there a release where this didn't happen?). This causes the NodeOut() > > results to become a little different, which act

Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)

Hannu Krosing <[EMAIL PROTECTED]> writes: > 1) record the lowest uncommitted transaction number (LUTN) , this may > have problems with wraparound, but I guess they are solvable. Disllow > VACUUM. Do a CHECKPOINT ('alter database begin backup') > 3) make a file-level (.tar) backup of data directory

Re: [HACKERS] Units for storage of internal time zone offsets

Thomas Lockhart <[EMAIL PROTECTED]> writes: > We have "always" stored our time zone offsets in a compressed > divide-by-ten form to allow storage in a single byte. But there are a > few time zones ending at a 45 minute boundary, which "minutes divided by > 10" can not represent. Is there a reaso

Re: [HACKERS] Postgres Projects

Christopher Kings-Lynne wrote: > Hi all, > > Just wondering - what is everyone working on? There's not much going on on > the list at the moment save lots of talk about DROP COLUMN and CREATE > CONVERSION. > > What's going on in everyone's pipelines? I am working on query_timeout right now. -

Re: [HACKERS] Units for storage of internal time zone offsets

Thomas Lockhart <[EMAIL PROTECTED]> writes: >> Is there a reason for the restriction to one byte? Offhand I don't >> recall that we store TZ offsets on disk at all... > Ah, we don't. Sorry I wasn't clear. This is only for the lookup table we > use to interpret time zones on *input*. It is contai

Re: [HACKERS] pg_tables and schemas

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > Does the pg_tables view need to be fixed now that we have schemas? Yeah, many of the system views need work. I haven't stopped to think about it yet. If anyone else wants to come up with a proposal, go for it... re

Re: [HACKERS] (A) native Windows port

On Monday 08 July 2002 03:20 pm, Jan Wieck wrote: > Zeugswetter Andreas SB SD wrote: > > Unless it dumps binary representation of columns, a standalone dumper > > would still need to load all the output function shared libs for custom > > types (or not support custom types which would imho not be

[HACKERS] Units for storage of internal time zone offsets

We have "always" stored our time zone offsets in a compressed divide-by-ten form to allow storage in a single byte. But there are a few time zones ending at a 45 minute boundary, which "minutes divided by 10" can not represent. But "minutes divided by 15" can represent this and afaik all other t

Re: [HACKERS] Proposal: CREATE CONVERSION

On Tue, 2002-07-09 at 03:47, Tatsuo Ishii wrote: > > An aside: I was thinking about this some, from the PoV of using our > > existing type system to handle this (as you might remember, this is an > > inclination I've had for quite a while). I think that most things line > > up fairly well to allow

[HACKERS] Postgres Projects

Hi all, Just wondering - what is everyone working on? There's not much going on on the list at the moment save lots of talk about DROP COLUMN and CREATE CONVERSION. What's going on in everyone's pipelines? Cheers, Chris ---(end of broadcast)---

Re: [HACKERS] DROP COLUMN Progress

> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > >> That was my first thought also, but then the wrong attnum would be used > >> in the "make_var". Ugh. I think what Chris needs to do is extend the > >> eref data structure so that there can be placeholders for dropped > >> attributes.

[HACKERS] Subject: 6.3.1: Core during initdb on SVR4 (MIPS)

With reference to the following mesage...We are wondering what was the resolution for the core.. thanks gautam 6.3.1: Core during initdb on SVR4 (MIPS) * From: Frank Ridderbusch <[EMAIL PROTECTED] > * To: [EMAIL PROTECTED] *

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote: > > Oh, that is a problem. We would have to require the old executables. > > Could this be solved with packaging? Meaning can postmasters from old versions > be packed with a new release strictly for the purpose of upgrading? It is my >

[HACKERS] Help Unsubscribing

How do I unsubscribe from here? Thank You, Anthony ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

[HACKERS] More fun with BETWEEN

I've nearly finished off the patch Christopher distributed. Creates the between node, and passes all regression tests except horology. I need to update outfuncs and readfuncs -- but hope to fix the below first. Seems I have a funny case left (Note the last comparison should be false): regress

Re: [HACKERS] Proposal: CREATE CONVERSION

SQL99 allows on the fly encoding conversion: CONVERT('aaa' USING myconv 'bbb') So there could be more than 1 conversion for a paticlular encodings pair. This lead to an ambiguity for "default" conversion used for the frontend/backend automatic encoding conversion. Can we add a flag indicating th

Re: [HACKERS] Proposal: CREATE CONVERSION

> > If so, what about the "coercibility" property? > > The standard defines four distinct coercibility properties. So in > > above my example, actually you are going to define 80 new types? > > (also a collation could be either "PAD SPACE" or "NO PAD". So you > > might have 160 new types). > > We

Re: [HACKERS] Proposal: CREATE CONVERSION

> > I've been think this for a while too. What about collation? If we add > > new chaset A and B, and each has 10 collations then we are going to > > have 20 new types? That seems overkill to me. > > Well, afaict all of the operations we would ask of a type we will be > required to provide for ch

Re: [HACKERS] DROP COLUMN Progress

> That was my first thought also, but then the wrong attnum would be used > in the "make_var". Ugh. I think what Chris needs to do is extend the > eref data structure so that there can be placeholders for dropped > attributes. Perhaps NULLs could be included in the list, and then the > code wou

Re: [HACKERS] Proposal: CREATE CONVERSION

> I've been think this for a while too. What about collation? If we add > new chaset A and B, and each has 10 collations then we are going to > have 20 new types? That seems overkill to me. Well, afaict all of the operations we would ask of a type we will be required to provide for character sets

Re: [HACKERS] Proposal: CREATE CONVERSION

> > (1) a CONVERSION can only be dropped by the superuser or its owner. > > Okay ... > > > (2) a grant syntax for CONVERSION is: > > > GRANT USAGE ON CONVERSION to > > { | GROUP | PUBLIC} [, ...] > > No, I don't think a conversion has any privileges of its own at all. > You either ha

[HACKERS] pg_tables and schemas

Tom, Does the pg_tables view need to be fixed now that we have schemas? Yep: test2=# create schema a; CREATE SCHEMA test2=# create schema b; CREATE SCHEMA test2=# create table a.test (a int4); CREATE TABLE test2=# create table b.test (b int4); CREATE TABLE test2=# select * from pg_tables where

Re: [HACKERS] Proposal: CREATE CONVERSION

> When you say "We do not yet implement the SQL99 forms of character > support", I think you mean the ability to specify per column (or even > per string) charset. I don't think this would happen for 7.3(or 8.0 > whatever), but sometime later I would like to make it reality. Right. An aside: I w

Re: [HACKERS] Proposal: CREATE CONVERSION

> > Here is a proposal for new pg_conversion system table. Comments? > > I wonder if the encodings themselves shouldn't be represented in some > system table, too. Admittedly, this is nearly orthogonal to the proposed > system table, except perhaps the data type of the two encoding fields. That

Re: [HACKERS] DROP COLUMN Progress

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: >> What of >> SELECT a,c,d FROM test >> I'll bet that doesn't work at all... > Yeah, broken. Damn. Yup. That loop we were just looking at needs to derive the correct attnum when it matches a column name. If you remove deleted columns from

Re: [HACKERS] Proposal: CREATE CONVERSION

> > Use a simple wrap function. > > How knows this function to/from encoding? For example you want to define a function for LATIN1 to UNICODE conversion function would look like: function_for_LATIN1_to_UTF-8(from_string opaque, to_string opaque, length integer) { : : g

Re: [HACKERS] Proposal: CREATE CONVERSION

> If so, what about the "coercibility" property? > The standard defines four distinct coercibility properties. So in > above my example, actually you are going to define 80 new types? > (also a collation could be either "PAD SPACE" or "NO PAD". So you > might have 160 new types). Well, yes I supp

Re: [HACKERS] DROP COLUMN Progress

> > test=# create table test (a int4, b int4, c int4, d int4); > > CREATE TABLE > > test=# insert into test values (1,2,3,4); > > INSERT 16588 1 > > test=# alter table test drop b; > > ALTER TABLE > > test=# select * from test; > > a | d | d > > ---+---+--- > > 1 | 3 | 4 > > (1 row) > > What of

Re: [HACKERS] (A) native Windows port

> > Keys to this working: > > 1.) Must not require the old version executable backend. There are a number > > of reasons why this might be, but the biggest is due to the way much > > upgrading works in practice -- the old executables are typically gone by the > > time the new package is inst

Re: [HACKERS] Proposal: CREATE CONVERSION

Tatsuo Ishii <[EMAIL PROTECTED]> writes: >> I believe the spec just demands USAGE on the underlying function for >> the TRANSLATE case, and I don't see why it should be different for >> CONVERT. (In principle, if we didn't use a C-only API, you could >> just call the underlying function directly;

Re: [HACKERS] Proposal: CREATE CONVERSION

> I believe the spec just demands USAGE on the underlying function for > the TRANSLATE case, and I don't see why it should be different for > CONVERT. (In principle, if we didn't use a C-only API, you could > just call the underlying function directly; so there's little point > in having protecti

Re: [HACKERS] DROP COLUMN Progress

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: >> Are you checking access to columns that're to the right of the one >> dropped? > OK, interesting: > test=# create table test (a int4, b int4, c int4, d int4); > CREATE TABLE > test=# insert into test values (1,2,3,4); > INSERT 16588 1 > te

Re: [HACKERS] Scope of constraint names

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> A considerable advantage of per-relation constraint names is that a new >> unique name can be assigned for a nameless constraint while holding only >> a lock on the target relation. We'd need a global lock to create unique >> cons

Re: [HACKERS] Proposal: CREATE CONVERSION

> Tatsuo, it seems that we should use SQL99 terminology and commands where > appropriate. We do not yet implement the SQL99 forms of character > support, and I'm not sure if our current system is modeled to fit the > SQL99 framework. Are you suggesting CREATE CONVERSION to avoid > infringing on SQ

Re: [HACKERS] (A) native Windows port

On Tue, 2002-07-09 at 00:20, Jan Wieck wrote: > Zeugswetter Andreas SB SD wrote: > > > > > No, what I envisioned was a standalone dumper that can produce dump output > > > without having a backend at all. If this dumper knows about the various > > > binary formats, and knows how to get my data i

Re: [HACKERS] Proposal: CREATE CONVERSION

Tatsuo Ishii writes: > Here is a proposal for new pg_conversion system table. Comments? I wonder if the encodings themselves shouldn't be represented in some system table, too. Admittedly, this is nearly orthogonal to the proposed system table, except perhaps the data type of the two encoding f

Re: [HACKERS] (A) native Windows port

Zeugswetter Andreas SB SD wrote: > > > No, what I envisioned was a standalone dumper that can produce dump output > > without having a backend at all. If this dumper knows about the various > > binary formats, and knows how to get my data into a form I can then restore > > reliably, I will be sa

Re: [HACKERS] DROP COLUMN Progress

Christopher Kings-Lynne wrote: > > > I am still looking but perhaps you could supress dropped columns from > > > getting into eref in the first place. > > > > OK, that's done. I'm working on not allowing dropped columns in UPDATE > > targets now. > > OK, I've fixed it so that dropped columns can

  1   2   >