Masaru Sugawara wrote:
Hi, all
While trying dblink_exec(), one of dblink()'s functions, I noticed there was an
odd situation: case 1 and case 2 worked well, but case 3 didn't(see below).
I hadn't been aware of it so that I only executed BEGIN and END in
dblink_exec() at first . This time, howev
Mike Mascari wrote:
How can dblink() possibly be used safely for non-readonly transactions
without a full implementation of a two-phase commit protocol? What
happens when the remote server issues the COMMIT and then the local
server crashes?
It can't be used safely if you're trying to ensure
Masaru Sugawara wrote:
I'm hoping that dblink_exec() returns something like warning if those who intend
to do transactions make a declaration of blink_exec('dbname=some', 'begin') by mistake.
for example
WARNING :You should declare dblink_exec('dbname=some', 'BEGIN; some queries;
COMMIT/ROLLBA
On Sat, 12 Oct 2002, Joe Conway wrote:
> Tom Lane wrote:
> > Hackers: we might reasonably fix this by doing a deep copy of the
> > relcache's trigger info during initResultRelInfo(); or we could fix it
> > by getting rid of ri_TrigDesc and re-fetching from the relcache every
> > time. The former
Tom Lane wrote:
I would say that that is a very bad decision in the JDBC driver and
should be reverted ... especially if the driver is not bright enough
to notice the context in which the parameter is being used. Consider
for example
...
You are trying to mask a server problem in the driver.
Tom Lane wrote:
Hackers: we might reasonably fix this by doing a deep copy of the
relcache's trigger info during initResultRelInfo(); or we could fix it
by getting rid of ri_TrigDesc and re-fetching from the relcache every
time. The former would imply that trigger state would remain unchanged
thr
Barry Lind <[EMAIL PROTECTED]> writes:
> create table test (col_a bigint);
> update test set col_a = nullif('200', -1);
> The above works fine on 7.2 but the update fails on 7.3b2 with the
> following error:
> ERROR: column "col_a" is of type bigint but expression is of type text
> You will
create table test (col_a bigint);
update test set col_a = nullif('200', -1);
The above works fine on 7.2 but the update fails on 7.3b2 with the
following error:
ERROR: column "col_a" is of type bigint but expression is of type text
You will need to rewrite or cast the expression
Is this chan
Hi, all
While trying dblink_exec(), one of dblink()'s functions, I noticed there was an
odd situation: case 1 and case 2 worked well, but case 3 didn't(see below).
I hadn't been aware of it so that I only executed BEGIN and END in
dblink_exec() at first . This time, however, I noticed it by exec
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> I see triggers referenced here and it should be
> noted that for one of the tables the triggers were first disabled (update
> pg_class) and re-enabled after the inserts are done (or it takes
> forever).
>>
>> Did that happen while this backend was ru
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Is there some established way of debugging the bootstrapping sequence?
> If not, does anyone have a tip on how would one do it?
> I mean getting the standalone boostrapping backend into gdb...
I'd just run the backend under gdb, passing it the same comm
That doesn't seem to work any more:
help set [EMAIL PROTECTED]
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
help unknowntopic
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ERROR - the document you requested is not available.
= = = = = = = = = =
Hello hackers,
Is there some established way of debugging the bootstrapping sequence?
If not, does anyone have a tip on how would one do it?
I mean getting the standalone boostrapping backend into gdb...
Thank you.
--
Alvaro Herrera ()
"La naturaleza, tan fragil, tan expuesta a la muerte... y
Hi,
I must be missing something obvious here but it seems that bitfromint4
is not working under 7.3b2. I can still see bitfromint4 in the source
code, utils/adt/varbit.c, but it is no longer working. Any ideas why?
Best wishes,
Neophytos
PS. It is also not working with the latest CVS checkout.
Isn't this a bug?
regression=# create table FOO (f1 int);
CREATE TABLE
regression=# \copy FOO from stdin
ERROR: Relation "FOO" does not exist
\copy: ERROR: Relation "FOO" does not exist
regression=#
This happens because \copy takes the given table name and slaps
double quotes around it, so the
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> On Sat, Oct 12, 2002 at 12:43:37 +0300,
> Antti Haapala <[EMAIL PROTECTED]> wrote:
>> What about copy? AFAIK, copy doesn't allow column names being specified,
>> so it's not purely aesthetic...
> The SQL COPY command does (at least in 7.3). The \copy
Neophytos Demetriou <[EMAIL PROTECTED]> writes:
> I must be missing something obvious here but it seems that bitfromint4
> is not working under 7.3b2. I can still see bitfromint4 in the source
> code, utils/adt/varbit.c, but it is no longer working. Any ideas why?
It's still there:
regression=#
Steven Singer <[EMAIL PROTECTED]> writes:
> I've been testing contrib/dbmirror with 7.3 and schema's and have come
> across a problem.
> SPI_getrelname(tg_relation) can be used by a trigger to get the name of
> the table that the trigger was fired on. But that just gives the
> tablename and not
Bruce Momjian wrote:
> Now that we are changing relfilenode in 7.3, I think we need to rename
> oid2name to relfilenode2name, and perhaps move it into the main tree.
>
> TODO item added:
>
> Rename oid2name to relfilenode2name and install by default
>
Actually, to be accurate, I think dat
I've been testing contrib/dbmirror with 7.3 and schema's and have come
across a problem.
SPI_getrelname(tg_relation) can be used by a trigger to get the name of
the table that the trigger was fired on. But that just gives the
tablename and not the schema that the table is in. If you have a s
Justin Clift wrote:
> Bruce Momjian wrote:
> >
> > Bruce Momjian wrote:
> > > Now that we are changing relfilenode in 7.3, I think we need to rename
> > > oid2name to relfilenode2name, and perhaps move it into the main tree.
> > >
> > > TODO item added:
> > >
> > > Rename oid2name to relfile
Bruce Momjian wrote:
>
> Bruce Momjian wrote:
> > Now that we are changing relfilenode in 7.3, I think we need to rename
> > oid2name to relfilenode2name, and perhaps move it into the main tree.
> >
> > TODO item added:
> >
> > Rename oid2name to relfilenode2name and install by default
Shou
Now that we are changing relfilenode in 7.3, I think we need to rename
oid2name to relfilenode2name, and perhaps move it into the main tree.
TODO item added:
Rename oid2name to relfilenode2name and install by default
--
Bruce Momjian| http://candle.pha.pa.us
On Sat, Oct 12, 2002 at 12:43:37 +0300,
Antti Haapala <[EMAIL PROTECTED]> wrote:
>
> > I cannot think of any reason why changing column order should be
> > implemented in Postgres. Seems like a waste of time/more code bloat for
> > something which is strictly asthetic.
>
> What about copy? AFAI
Justin Clift wrote:
> Hi all,
>
> As an end result of all this, do we now have a decent utility by which
> end user admin's can run it against the same disk/array that their
> PostgreSQL installation is on, and get a reasonably accurate number for
> random page cost?
>
> ie:
>
> $ ./get_calc_co
Hannu Krosing wrote:
> Alvaro Herrera kirjutas L, 12.10.2002 kell 04:16:
> > On Fri, Oct 11, 2002 at 07:08:18PM -0700, Jeff Davis wrote:
> >
> > > And it really is a minor matter of convenience. I end up dropping and
> > > recreating all my tables a lot in the early stages of development, which
Hi all,
As an end result of all this, do we now have a decent utility by which
end user admin's can run it against the same disk/array that their
PostgreSQL installation is on, and get a reasonably accurate number for
random page cost?
ie:
$ ./get_calc_cost
Try using random_page_cost = foo
$
:
On 12 Oct 2002 at 2:54, Jeff Davis wrote:
> As far as I can tell, the order the attributes are returned makes no
> difference in a client application, unless you're referencing attributes by
> number. All applications that I've made or seen all use the name instead, and
> I've never heard other
On 12 Oct 2002, Hannu Krosing wrote:
> Alvaro Herrera kirjutas L, 12.10.2002 kell 04:16:
> > On Fri, Oct 11, 2002 at 07:08:18PM -0700, Jeff Davis wrote:
> >
> > > And it really is a minor matter of convenience. I end up dropping and
> > > recreating all my tables a lot in the early stages of dev
> >
> > Did attlognum's (for changing column order) get implemented for 7.2 ?
>
> I cannot think of any reason why changing column order should be
> implemented in Postgres. Seems like a waste of time/more code bloat for
> something which is strictly asthetic.
>
> Regardless, I do have collegues/cl
> I cannot think of any reason why changing column order should be
> implemented in Postgres. Seems like a waste of time/more code bloat for
> something which is strictly asthetic.
What about copy? AFAIK, copy doesn't allow column names being specified,
so it's not purely aesthetic...
-
Alvaro Herrera kirjutas L, 12.10.2002 kell 04:16:
> On Fri, Oct 11, 2002 at 07:08:18PM -0700, Jeff Davis wrote:
>
> > And it really is a minor matter of convenience. I end up dropping and
> > recreating all my tables a lot in the early stages of development, which is
> > mildly annoying. Certain
Giles Lean <[EMAIL PROTECTED]> writes:
> Portable code uses 'unsigned char' when using ctype.h features, even
> though for many platforms where 'char' is an unsigned type it's not
> necessary for correct functioning.
Yup. Awhile back I went through the PG sources and made sure we
explicitly caste
33 matches
Mail list logo
