Hello to everybody!
I've a little problem with LOCK-ing a
certain row in a table using PHP and
PostgreSQL on LINUX.
>> In a few words, I'd like to undertand
>> how find out if a certain row is locked,
>> in order to prevent a kind of deadlock.
Which is the (system) table where all
locked row
Hi all,
It would be very nice if PL/PgSQL could return a record set (ie, set of
tuples). This could be done in two ways as far as I can imagine: either
PL/PgSQL just returns the rows as a normal query would or it could return
a cursor. The prior would be very useful, the latter easier to implemen
* Tatsuo Ishii <[EMAIL PROTECTED]> [011014 16:05]:
> > > ASCII SQL_ASCII
> > > UTF-8 UNICODE UTF_8
> > > MULE-INTERNAL MULE_INTERNAL
> > > ISO-8859-1LATIN1 ISO_8859_1
> > > ISO-8859-2LATIN2
You already can return a cursor.
Support for returning a record set is being worked on.
-alex
On Sun, 14 Oct 2001, Gavin Sherry wrote:
> Hi all,
>
> It would be very nice if PL/PgSQL could return a record set (ie, set of
> tuples). This could be done in two ways as far as I can imagine: either
> Bruce Momjian writes:
>
> > > Bruce Momjian writes:
> > >
> > > > OK, new FAQ code is:
> > > >
> > > > $sql = "SELECT nextval('person_id_seq')";
> > > > $newSerialID = ($conn->selectrow_array($sql))[0];
> > > > INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
>
> Obviously, someone did because they tried the code and it didn't work.
> At least the new code is closer to valid, though less clear. It is at
> least a valid snippet, which the previous version was not.
OK, I changed it to more pseudocode:
new_id = output of "SELECT nextval('person_id_s
> * Tatsuo Ishii <[EMAIL PROTECTED]> [011014 16:05]:
> > > > ASCII SQL_ASCII
> > > > UTF-8 UNICODE UTF_8
> > > > MULE-INTERNAL MULE_INTERNAL
> > > > ISO-8859-1 LATIN1 ISO_8859_1
> > > > ISO-8859-2 LATIN2
I have committed part of Patrice's patches with minor fixes.
Uncommitted changes are related to the backend side, and the reason
could be found in the previous discussions (basically this is due to
the fact that current regex code does not support UTF-8 chars >=
0x1). Instead pg_veryfymbstr()
On Sat, 13 Oct 2001, Tom Lane wrote:
> Bill Studenmund <[EMAIL PROTECTED]> writes:
> > For functions and aggregates, things are a little more complicated. First
> > off, there is a package called "standard" which contains all types,
> > aggregates, operators, and functions which aren't in a speci
Bruce Momjian writes:
> > Bruce Momjian writes:
> >
> > > OK, new FAQ code is:
> > >
> > > $sql = "SELECT nextval('person_id_seq')";
> > > $newSerialID = ($conn->selectrow_array($sql))[0];
> > > INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
> > > $res = $db
I'm not sure what the answer to your problem is, but I'm sure you have the
wrong approach.
For all practical purposes, client/server database programming is a
multiprocessing problem set. What you are trying to implement is a mutex. A
mutex is a mutual exclusion tool. You can't reliably do what y
Thanks Tom,
patch will be submitted.
regards,
Oleg
On Fri, 12 Oct 2001, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > we'd like to submit new module contrib/tsearch which
> > contains implementation of new data type txtidx -
> > a searchable data type
Tom Lane writes:
> This seems like it will overlap and possibly conflict with the decisions
> you've made for packages. It also seems possible that a package *is*
> a schema, if schemas are defined that way --- does a package bring
> anything more to the table?
I have been pondering a little ab
How would authentication and access control be done with a preforking
backend? I personally find a preforking backend desirable, but that's just me.
But if people really want preforking how about not doing it in the backend.
Create a small program that makes a few connections to postgresql, does
Also note that an uncommitted select statement will lock the table and
prevent vacuum from running. It isn't just inserts/updates that will
lock and cause vacuum to block, but selects as well. This got me in the
past. (Of course this is all fixed in 7.2 with the new vacuum
functionality tha
> > Oh yeah. We don't have a date_part(units, time) function defined, so it
> > is getting converted to interval (which in other contexts *does* have
> > some usefulness as a "time equivalent").
> You're going to have an extremely hard time convincing me of that.
OK, thanks for the warning. I'll
> > In 7.1 I was able to get this (I thought) with
> > date_part(''epoch'', timestamp ''now'') . That doesn't seem to work for me
> > in last week's -current.
> Thomas, I think you broke something.
It was actually a side effect of changing the date/time parser to no
longer ignore unrecognized tex
17 matches
Mail list logo
