On Fri, 15 Dec 2000, Manika dey wrote:
>
> Hi,
> Can anyone help me .
> I want to know how
> to write triggers.
> i am using java and postgresql
not probably in java you can write function in some
"internal-interpreted-language": C, Perl, Tcl, SQL, PL/SQL
BTW, What is bad on PostgreSQL
On Sun, Dec 17, 2000 at 10:47:55PM -0500, Tom Lane wrote:
>
> A quick-and-dirty workaround would be to save and restore errno in
> reaper() and the other postmaster signal handlers. It might be
> a better idea in the long run to avoid doing system calls in the
> signal handlers --- but that woul
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think
> there are some papers at Berkeley or a web site that goes into it in
> detail.
I imagine there's some GiST stuff at the Berkeley papers repository
http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/papers/
but I'd be surprised if it's more than an o
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > I checked 7.1 feature list and didn't find any mention about GiST
> > but there are changes in GiST code. Who is a maintainer of GiST code ?
>
> You are ;-). If you expect to find someone who understands GiST better
> than you, you're probably out
Yes, I will take a pass over the logs before final. As noted in the
file, the list is accurate as of December 11.
> We're working hardly on bugfixes for GiST (I've posted patch for 7.0.3)
> and probably could finish in 1-2 weeks.
>
> regards,
> Oleg
> On Sat, 16 Dec 2000, Br
> Peter Bierman <[EMAIL PROTECTED]> writes:
> > At 3:16 PM -0500 12/16/00, Bruce Momjian wrote:
> >> Here is the list of features in 7.1.
> >> New Darwin/Mac OSX port (Bruce Hartzler)
>
> > Not to be a snob, but I probably did 80% of this.
>
> Bruce had submitted an earlier patch, but IIRC Peter
Is ther any info on using toast as of yet,
and if so where is it hidden
to?
Hi all,
Can anyone point the doc explaining how to assign a new admin level
account name and password? I can't seem to find it in docs or search
engines. Thanks.
R. Smith
Mathijs Brands <[EMAIL PROTECTED]> writes:
> We recently installed a small server for an external party to develop
> websites on. This machine, a K6-233 with 256 MB, is running FreeBSD 3.3
> and PostgreSQL 7.0.2 (maybe I'll upgrade to 7.0.3 tonight). The database
> it's running is about 2 MB in si
On Sunday 17 December 2000 19:10, Hiroshi Inoue wrote:
> Hannu Krosing wrote:
> > Tom Lane wrote:
> > >> ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
> > >
> > > critically dependent on heap_getattr returning NULL when an attribute
> > > beyond the number of attributes actu
This is what I assumed the problem to be but I wasn't sure if there would be
more to it or not.
My question now is: Should the order in which columns are physically stored
matter?
Since the details of where to find the columns in the tuple data are stored
in pg_attribute, I'd think this is a pla
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> > ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
> critically dependent on heap_getattr returning NULL when an attribute
> beyond the number of attributes actually present in a
At 9:43 PM -0400 12/17/00, The Hermit Hacker wrote:
>On Sat, 16 Dec 2000, Peter Bierman wrote:
>
>> (BTW- tons of stuff at www.postgresql.org is busted. Searching mailing
>> list archives for example.)
>
>Please provide URLs where you are trying to search ... we did extensive
>work over the past f
> > So there are two issues here which I hope to clarify: scoping
> > on joins, and NATURAL and USING join column sets.
> Two issues? I thought we were only arguing about the latter one.
Well, I prefer to consider it "discussing" ;)
And there are two issues. I'll bet lunch and dinner that SQL99
"Michael Richards" <[EMAIL PROTECTED]> writes:
> What are the cases where the current implementation does not handle it
> properly?
Inheritance.
CREATE TABLE parent (a, b, c);
CREATE TABLE child (z) INHERITS (parent);
ALTER TABLE parent ADD COLUMN (d);
With the current implementation you now
On Sat, 16 Dec 2000, Peter Bierman wrote:
> At 3:16 PM -0500 12/16/00, Bruce Momjian wrote:
> >Here is the list of features in 7.1.
> >New Darwin/Mac OSX port (Bruce Hartzler)
>
> Not to be a snob, but I probably did 80% of this.
>
> (BTW- tons of stuff at www.postgresql.org is busted. Searchin
Considering how often you actually change the structure of a database, I
don't mind waiting for such a reorganisation to take place, however it would
still be nice if it could be done in O(1) time because it would minimise the
amount of downtime required for structure changes.
What are the cases
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
> ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
critically dependent on heap_getattr returning NULL when an attribute
beyond the number of attributes actually present in a tuple is accessed.
Tha
"Mikheev, Vadim" wrote:
>
> > > Also, is TOAST-table vacuuming fixed now?
> >
> > Still broken. Hiroshi had muttered something about fixing
> > the internal commit of VACUUM so that it's more like a real
> > commit --- including advancing the transaction ID --- but
> > still doesn't release the e
Hannu Krosing wrote:
>
> Tom Lane wrote:
> >
> >> ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
> > critically dependent on heap_getattr returning NULL when an attribute
> > beyond the number of attributes actually present in a tuple is accessed.
> > That's a fragile and un
Okay. On this particular machine, the way I was loading in the page it
properly aligns the data to the page beginning, so I used that. I now have
it extracting meaningful data from a variety of tables. The very last thing
I need to do now is figure out where the code in the source is that stores
a
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> I checked 7.1 feature list and didn't find any mention about GiST
> but there are changes in GiST code. Who is a maintainer of GiST code ?
You are ;-). If you expect to find someone who understands GiST better
than you, you're probably out of luck.
I
"Michael Richards" <[EMAIL PROTECTED]> writes:
> Is this alignment relative to the beginning of the page or tuple, or even
> the tuple data area (after the tuple header)?
Well, it's absolute: on machines that care about such things, you *will*
coredump if you try to fetch an int at a non-4-byte-a
Tom Lane wrote:
>
>> ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
> critically dependent on heap_getattr returning NULL when an attribute
> beyond the number of attributes actually present in a tuple is accessed.
> That's a fragile and unclean implementation IMHO --- see
Hi,
I checked 7.1 feature list and didn't find any mention about GiST
but there are changes in GiST code. Who is a maintainer of GiST code ?
We have several problems with GiSt and would like to communicate
with somebody who understand these code.
Regards,
Oleg
__
Is this alignment relative to the beginning of the page or tuple, or even
the tuple data area (after the tuple header)?
-Michael
> "Michael Richards" <[EMAIL PROTECTED]> writes:
> > The alignment seems to be wrong for type CHAR(1):
>
> No, the alignment is fine. A field's align constraint says
We need additions to alter_table.sgml for the new OWNER option mention
in the features list.
--
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 you
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> To make a long story short, a more correct name for this option would be
> "--globals-only". Is it okay to change this?
Okay with me...
regards, tom lane
Write away ...
regards, tom lane
I said:
> The is equivalent to a
> sequence in which each is a column
> reference CR that references a column of TQ that is not
> a common column of a .
> which is essentially taken from 7.9.4 of the old spec. This is a mess;
Oops, I guess I assumed that the alignment part was directly related to the
number of bytes until the next attribute rather than the actual alignment.
Is there any need for documentation on how this whole storage thing works?
I'd be more than willing to write it up.
-Michael
- Original Mess
I've been sneaking a peek at the Great Bridge documentation regarding the
pg_dumpaccounts utility. You may recall that I added the pg_dumpall
--accounts-only option to provide the same functionality. But it occurred
to me that the name is wrong.
The way it reads in the GB docs is that pg_dumpac
"Michael Richards" <[EMAIL PROTECTED]> writes:
> The alignment seems to be wrong for type CHAR(1):
No, the alignment is fine. A field's align constraint says where it has
to start, not where the next field has to start. gender starts on a
4-byte boundary and is 5 bytes long, then we have one by
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> In particular, how can
> select t1.*, t2.* from t1 natural join t2;
> produce columns from t1 and t2 which are *not present* in the join "t1
> natural join t2"?
Very easily ;-)
>> What's even more interesting is that I can find no equivalent
>> t
Ok, just a small issue here:
I'm running:
select attname,attlen,attalign from pg_attribute where attnum>0 and attrelid
= (select oid from pg_class where relname = 'users') order by attnum;
This is to get the name, length of that attribute and the alignment.
The alignment seems to be wrong for typ
35 matches
Mail list logo
