Is there a reason for the following behavior?
nconway=# create table a (col1 int);
CREATE TABLE
nconway=# insert into a default values;
INSERT 1883513 1
nconway=# copy a to '/tmp/output';
COPY
nconway=# create view myview as select * from a;
CREATE VIEW
nconway=# copy myview to '/tmp/output';
ERR
Using a recent build (22.5) from CVS, if I create a set returning
function in SQL like this:
func_test=# CREATE TABLE foo (id INT, txt1 TEXT, txt2 TEXT);
CREATE TABLE
func_test=# INSERT INTO foo VALUES(1, 'Hello','World');
INSERT 24819 1
func_test=#
func_test=# CREATE OR REPLACE FUNCTION bar(in
The attached patch is my first pass at a sample C function returning
setof composite. It is a clone of SHOW ALL as an SRF. For the moment,
the function is implemented as contrib/showguc, although a few minor
changes to guc.c and guc.h were required to support it.
I wanted to post it to HACKERS
Tom Lane wrote:
> bar were in my search path, so I should not see them unless I give a
> qualified name (eg, "\d foo.mytab" or "\d bar.mytab"). For commands
> that accept wildcard patterns, what should happen --- should "\z my*"
> find these tables, if they're not in my search path? Is "\z f*.my
On Sat, 25 May 2002, Michael Meskes wrote:
> No, this is simply not true. The version number is what the upstream
> gives its release. No more no less. What RH does is becoming as subtly
> incompatible a possible. If that's the goal, it doesn't look like free
> software for me. Sure all changes a
Well, given that vacuum does its work in the background now - I think you'll
be hard pressed to find a sys admin who'll vote for leaving it as is, no
matter how small the chance of corruption.
However - this isn't my area of expertise...
Chris
- Original Message -
From: "Tom Lane" <[EMA
Add to TODO:
* Add getpid() function to backend
We have this in libpq, but it should be in the backend code as a
function call too.
---
Hannu Krosing wrote:
> On Tue, 2002-04-30 at 03:35, Bruce Momjian wrote:
> >
[2002-05-25 11:44] Tom Lane said:
| > In your responses you also raised the problem of COPY having to know about
| > default values for columns if we allow subsets of columns when we load
| > data; does that mean that COPY does something more fancy than the
| > equivalent of an INSERT?
|
| No,
[2002-05-23 10:51] Tom Lane said:
| "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
| > So who was it that wanted to make this change. Perhaps I can help.
|
| I forget who had volunteered to work on it, but it was several months
| ago and nothing's happened ...
I'd be the disappearing culprit...
Sure. src/tools/backend/flow.fig is the xfig source for the diagram. I
can generate a PDF if you wish, but you have to wait for me to return
from vacation on May 31. I only have telnet access right now.
---
Michael Meske
On Fri, May 24, 2002 at 12:15:47PM -0700, Ulrich Drepper wrote:
> This is getting silly. Does nobody here understand that the release
Yes, but I'm not sure on which side.
> number is local for each distribution. Comparing them does not lead to
No, this is simply not true. The version number i
If a VACUUM running concurrently with someone else's indexscan were to
delete the index tuple that the indexscan is currently stopped on, then
we'd get a failure when the indexscan resumes and tries to re-find its
place. (This is the infamous "my bits moved right off the end of the
world" error c
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> On Sat, 25 May 2002, Tom Lane wrote:
>> I get the same in current sources (in fact the number of rows updated
>> varies from try to try). Are you sure it's not a problem with the
>> gist index mechanism?
> We'll look once more, but code for select and
It occurs to me that we could get rid of the
ReferentialIntegritySnapshotOverride flag (which I consider both ugly
and dangerous) if we tweaked ExecutorStart to accept the snapshot-to-use
as a parameter. Then RI queries could pass in SnapshotNow instead of
the normal query snapshot, and we'd not
On Sat, 25 May 2002, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > test=# update tst set i = i+10 where a && '{3,4}';
> > UPDATE 3267
> > test=# set enable_indexscan=off;
> > SET VARIABLE
> > test=# update tst set i = i+10 where a && '{3,4}';
> > UPDATE 4060
>
> I get the sa
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> test=# update tst set i = i+10 where a && '{3,4}';
> UPDATE 3267
> test=# set enable_indexscan=off;
> SET VARIABLE
> test=# update tst set i = i+10 where a && '{3,4}';
> UPDATE 4060
I get the same in current sources (in fact the number of rows updat
Philip Warner <[EMAIL PROTECTED]> writes:
> Not sure if this is the right reference, but about 30-Apr-2001, Alfred
> Perlstein raised the problem of column names in COPY, and you poured water
> on the idea:
So I did, but I've changed my mind --- it would provide a usable solution
to this inheri
Here is a new contrib function called "pgstatindex", similar to
pgstattuple but different in that it returns the percentage of the
dead tuples of an index. I am posting this for review purpose.
Installation of pgstatindex is pretty easy:
unpack the tar package in contrib directory.
cd into pgsta
Sorry,
forget to attach file.
Oleg
On Sat, 25 May 2002, Oleg Bartunov wrote:
> Hi,
>
> we've got rather strange problem with updating and GiST indices.
> Below is a test run:
>
> drop table tst;
> create table tst ( a int[], i int );
> copy tst from stdin;
>
> \.
> create index tsti o
Hi,
we've got rather strange problem with updating and GiST indices.
Below is a test run:
drop table tst;
create table tst ( a int[], i int );
copy tst from stdin;
\.
create index tsti on tst using gist (a);
vacuum full analyze;
test=# update tst set i = i+10 where a && '{3,4}';
UPD
20 matches
Mail list logo
