Seems like a reasonable thing to submit.
Chris
mike g wrote:
Hello,
Going through the regress test sql files I noticed that when testing
string functions there was no upper / lower case tests.
I see upper / lower being used in the select_having and select_implicit
files in the GROUP BY and ORDER BY
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Would adding "OID" to the rows returned by each "Select" call, and then doing
> "update blah where oid=xxx" when I'm requested to update the row sound like a
> reasonable stategy, in lieu of updateable cursors? Can anyone suggest a better
> way?
If yo
Hello,
Going through the regress test sql files I noticed that when testing
string functions there was no upper / lower case tests.
I see upper / lower being used in the select_having and select_implicit
files in the GROUP BY and ORDER BY clauses.
Good enough or should I submit patch for adding
Yes, Slonik's,
it't true. After nearly a year the Slony-I project is entering the BETA
phase for the 1.0 release. Please visit
http://gborg.postgresql.org/project/slony1/news/newsfull.php?news_id=174
for further details.
Jan Wieck
--
#==
Doh, sorry. I just realised that the lists just gave me a whole bunch
of mails from back in February, which is when Tom made this post...
Chris
Christopher Kings-Lynne wrote:
Parsing is a whole nother ball of wax besides lexing. I wasn't planning
to put *that* into psql. Remember the only thin
Parsing is a whole nother ball of wax besides lexing. I wasn't planning
to put *that* into psql. Remember the only thing psql really wants from
this is to detect where end-of-statement is ...
OK, I'm not that great at understanding where lexing ands and parsing
starts. These are the things that
On Thu, Jun 03, 2004 at 05:38:21PM -0700, Jonathan Gardner wrote:
> Do you know of good resources on learning how transactions are implemented
> in PostgreSQL? Should I just peruse the code? Which files are most
> relevant?
backend/access/transam/xact.c (high level transaction status) and
backe
Seeing how PITR, nested transactions, and other exciting developments
related to transactions are being developed, I am getting curious about how
PostgreSQL actually implements transactions. Investigating Materialized
Views has led me to look closely at how transactions work and such.
Do you kn
> I agree with Tom here. I have used the Oracle NOWAIT feature in the
> past and think it is a great feature IMHO. But when you need to use it,
> you want it to apply very specifically to a single statement. Using a
> sledge hammer when you need a tweezers isn't the right way to go.
Once I h
--On Wednesday, February 18, 2004 13:56:14 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL commands.
Does anyone want to vote _against_ the GUC idea for nowait lock
On Sun, 15 Feb 2004, Stephan Szabo wrote:
> On Fri, 13 Feb 2004, Stephan Szabo wrote:
>
> >
> > On Fri, 13 Feb 2004, Tom Lane wrote:
> >
> > > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > > On Fri, 13 Feb 2004, Tom Lane wrote:
> > > >> I was looking at that last night. It seems like we could a
Magnus Hagander wrote:
> Without checking into details, this sounds like it could be a broken
> ming/msys installation. Are you on the latest release version?
>
> Also, check for the Makefile.port file manually. configure cleraly
> thinks it has created it... If it's not there, check if you can c
Hi all,
I'm in the process of writing an OLE DB provider for postgres. I am,
right now, at the point where updating an entry becomes an issue.
Ideally, I would open an updateable cursor for a table/view, and use
that. Unfortunetly, Postgres doesn't seem to support those at all.
As an alternativ
Alvaro Herrera wrote:
> On Wed, Jun 02, 2004 at 10:57:05AM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> >
> > > No, I said own xid --- so the "phantom xid" part is still there. But
> > > your idea definitely does *not* work unless you use a single CID
> > > sequence for the whole main xact; a
On Wed, Feb 18, 2004 at 01:40:00AM -, Greg Sabino Mullane wrote:
> Fabrizio Mazzoni asked:
>
> > How can i find out if a prepared statement already exists..? Is there a
> > function or a query i can execute ..??
>
> I have not seen an answer to this, and I am curious as well. Anyone?
Try
On Wed, Jun 02, 2004 at 10:57:05AM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
>
> > No, I said own xid --- so the "phantom xid" part is still there. But
> > your idea definitely does *not* work unless you use a single CID
> > sequence for the whole main xact; and I'm still wondering if there's
Tom Lane <[EMAIL PROTECTED]> writes:
> The difficulty with acquiring lock earlier is that to acquire lock,
> you need to know the relation's shared/unshared status as well as
> its OID. We'd need to do something with all the code that assumes
> that an OID is sufficient information for opening rel
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
>>> Are the zic files something that should be updated for every minor
>>> release, or only for every major release?
>>
>> AFAIK they don't change very often.
>>
> I'm not sure. In Brazil, we change it every year 'cause we have 'summer
> time
Hi Tom,
> > Are the zic files something that should be updated for every minor
> > release, or only for every major release?
>
> AFAIK they don't change very often.
>
I'm not sure. In Brazil, we change it every year 'cause we have 'summer
time'. See src/timezone/data/southamerica
I think we can
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> I tried running 'make installcheck' in contrib just now, and didn't
> get past btree_gist :-(
> Fix and test on Alpha box.
Works for me on HPPA now, too. Thanks.
regards, tom lane
---(end of broadcast)-
I was just looking at this macro:
/*
* PageGetMaxOffsetNumber
*Returns the maximum offset number used by the given page.
*Since offset numbers are 1-based, this is also the number
*of items on the page.
*
*NOTE: to ensure sane behavior if the page is not initi
I tried running 'make installcheck' in contrib just now, and didn't
get past btree_gist :-(
Fix and test on Alpha box.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your
Dear Tom,
> > Due to how ACL are defined in SQL, I restate my suggestion that the super
> > user should be able to change ANY right, including the GRANTOR field,
>
> I'm unconvinced of this: that philosophy soon leads you into allowing
> the superuser to create self-inconsistent sets of rights, s
23 matches
Mail list logo
