headers
Jeff Davis | 1 Oct 2002 01:13

composite types in 7.3


I tried:
test=> create type mytype as (a int, b text);
CREATE TYPE
test=> create table mytable(x mytype,y int);
CREATE TABLE

It seemed to succeed OK, but did I do anything worthwhile? Since composite 
functions don't have input/output functions, I don't know how to actually 
create a record in mytable.

Are composite functions supposed to be used in this way? I know that composite 
types can be used so that a function can return a record of that type, but is 
there any other use?

Regards,
	Jeff

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org
Permalink | Reply | 2 comments |
headers
Martijn van Oosterhout | 1 Oct 2002 01:41
Favicon

Re: cursors

On Mon, Sep 30, 2002 at 11:24:06AM -0500, Hector Galicia wrote:
> Hi
> I'm new using postgressql, so my questions is about
> the use of cursors. I'm already know how to define,
> open and assign into a variable, but what I don't know
> is when the cursor is empty. Exist a function that
> tells me when the cursor is empty?

The way I tell is when you do a FETCH <n> and you get less than <n> results
back.

--

-- 
Martijn van Oosterhout   <kleptog <at> svana.org>   http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org
Permalink | Reply | 0 comments |
headers
Joe Conway | 1 Oct 2002 01:46
Gravatar

Re: composite types in 7.3

Jeff Davis wrote:
> I tried:
> test=> create type mytype as (a int, b text);
> CREATE TYPE
> test=> create table mytable(x mytype,y int);
> CREATE TABLE
> 
> It seemed to succeed OK, but did I do anything worthwhile? Since composite 
> functions don't have input/output functions, I don't know how to actually 
> create a record in mytable.
> 
> Are composite functions supposed to be used in this way? I know that composite 
> types can be used so that a function can return a record of that type, but is 
> there any other use?

Not at the moment. In fact, as of current (meaning by the time beta3 is 
packaged up, if it's not already this way in beta2) cvs you'll get:

test=# create type mytype as (a int, b text);
CREATE TYPE
test=# create table mytable(x mytype,y int);
ERROR:  Attribute "x" has composite type mytype

There have been brief discussions of allowing composite types as table column 
data types in some future release, but nothing serious yet.

Joe

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(Continue reading)

Permalink | Reply | 1 comment |
headers
Williams, Travis L, NPONS | 1 Oct 2002 02:08
Picon
Favicon

Vacuum question..

I have a DB that's about 1000 rows and 100 columns with 97 of them being updated every 20-30 min.  This DB is
basically all of the data that I poll off of 1000 different machines thats used by different scripts.  How
often should I run Vacuum?  Would I be better off doing it every time after I do my updates?

Travis

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html
Permalink | Reply | 1 comment |
headers
Jeff Davis | 1 Oct 2002 02:53

Re: composite types in 7.3

> Not at the moment. In fact, as of current (meaning by the time beta3 is
> packaged up, if it's not already this way in beta2) cvs you'll get:
>
> test=# create type mytype as (a int, b text);
> CREATE TYPE
> test=# create table mytable(x mytype,y int);
> ERROR:  Attribute "x" has composite type mytype
>
> There have been brief discussions of allowing composite types as table
> column data types in some future release, but nothing serious yet.

I don't have any particular need for that feature, but I found it interesting. 
I imagine that if the feature did exist like that, it would require a lot of 
extra syntax for the queries.

Thanks,
	Jeff

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org
Permalink | Reply | 0 comments |
headers
Tom Lane | 1 Oct 2002 07:15
Picon

OS X loader failure (was Re: Beta2 - A Late Announcement)

Adam Witney <awitney <at> sghms.ac.uk> writes:
> [ bad shared library causes backend coredump on OS X ]

This patch seems to suppress the coredump:

http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/port/dynloader/darwin.c.diff?r1=1.5&r2=1.6

However, instead of a somewhat-useful error message on postmaster
stderr, you now get only "no message available".  This sucks :-(.
Apparently, asking not to crash overrides the default error handler
that prints the useful error message before crashing.

I applied the patch anyway, since a backend crash is considerably more
Not Acceptable than not telling you why the shlib can't be loaded.
But getting the error message too would be much better.  Apparently,
if we want the message too, we have to create a 'linkEdit' hook to print
it --- see
http://developer.apple.com/techpubs/macosx/DeveloperTools/MachORuntime/5rt_api_reference/_Object_Fil_e_Functions.html
for some pointers.

Any OSX users care to code up the error-printing routine?

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yury Bokhoncovich | 1 Oct 2002 09:27
Picon

Re: 7.0 -> 7.2 Migration (oops)

Hello!

On Fri, 27 Sep 2002, Lamar Owen wrote:

> On Friday 27 September 2002 09:46 am, Glen Baker wrote:
> > Whups...I just upgraded my linux system from Redhat 7.1 to 7.3. As a part
> > of that upgrade my postgres installation was also upgraded from 7.0 to
> > 7.2.1.
> 
> > Is there any way that I can migrate the databases after the fact? Had I
> > realized this was going to happen I would have dumped them beforehand, but
> > it's a bit late now..
> 
> It's mentioned in the Red Hat 7.3 release notes.
> 
> Anyway, that doesn't help you.  You _might_ be able to reinstall your 
> PostgreSQL 7.0 RPM's from your Red Hat 7.1 install media.  Get all the 

BTW, there is no need in this. It is enough to get just postmaster from 
RPM. Easiest method is thru MC :-):
 just click to old PG RPM, select usr/bin, then copy postmaster and 
pg_dumpall to your home directory.
Start old postmaster, then run pg_dumpall >somefile, stop postmaster (just 
do killall postmaster). That's all.
You'd start the new PG and do psql -f somefile...

--

-- 
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg <at> center-f1.ru.
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shridhar Daithankar | 1 Oct 2002 09:37
Picon

Re: Vacuum question..

On 30 Sep 2002 at 20:08, Williams, Travis L, NPONS wrote:

> I have a DB that's about 1000 rows and 100 columns with 97 of them being updated every 20-30 min.  This DB is
basically all of the data that I poll off of 1000 different machines thats used by different scripts.  How
often should I run Vacuum?  Would I be better off doing it every time after I 
do my updates?

Well no. I would say every 15 minutes would be a good idea.

How often do you query the table? Vacuum can do three things for you.

1) Update statistics so that planner chooses correct plan thus improving 
performance.

2) Update causes dead tuples of earlier verson. Vacuum analyze marks these dead 
tuples for reuse so that resources are used efficiently.

3) Vacuum full also retrieves any lost disk space when you do a bulk delete.

Clearly in your case, (2) seems to be predominant factor. So I would say a 
vacuum analyze <tablename> for each 15 minutes will keep things in good 
shape..Even half an hour would do..

Bye
 Shridhar

--
Nachman's Rule:	When it comes to foreign food, the less authentic the better.		-
- Gerald Nachman
(Continue reading)

Permalink | Reply | 0 comments |
headers
Achilleus Mantzios | 1 Oct 2002 09:49

Re: [SQL] arrays


I was wondering why is such a rage against arrays.

I posted 2 very common problems where arrays provide
the only natural (and efficient) fit. (and got no responses)
So it seems to me that:

- Arrays implementation (along with the intarray package) in postgresql
  is well performing and stable.
- Some problems shout out for array usage.
- The Array interface is defined in java.sql package.
  (I dont know if sql arrays is in some standard but it seems that
  Java sees it that way, at least).
- The Array interface is implemented in the official postgresql java
package.
- In some problems replacing arrays according the tradition relational
paradigm would end up in a such a performance degradation, that
some applications would be unusable.
- Oleg and Teodor did a great job in intarray, making array usage
 easy and efficient.

Thanx!

==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrey Mosienko | 1 Oct 2002 11:56
Picon

Inet arrays in PostgreSQL


Hello All!

I am using your Array iterator functions contributed with PostgreSQL.
It is very useful thing and it works well.

But I need functions to work with inet[] and bigint arrays.
Has somebody ever created them?

If you have send me it please.
If no, please explain me how to do it?

--

-- 
with respection Andrey Feofilactovich.
e-mail: feo <at> ttn.ru, feo <at> feo.org.ru
ICQ: 28073807

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo <at> postgresql.org)
Permalink | Reply | 1 comment |

Gmane