On Sat, Jul 03, 2004 at 11:12:56PM -0400, Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I haven't looked at JDBC, but at least in the libpq code, what we could
> >> safely do is extend the existing no transaction/in transaction/in failed
> >> transaction field
On Sat, Jul 03, 2004 at 11:33:35PM -0400, Mike Mascari wrote:
> The fact that novices can't pronounce the name correctly is a
> problem. People will be afraid to raise the possibility as a
> solution in the enterprise if they think they'll look like a fool
> pronouncing the name aloud. I rememb
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I haven't looked at JDBC, but at least in the libpq code, what we could
safely do is extend the existing no transaction/in transaction/in failed
transaction field to provide a five-way distinction: those three cases
plus in s
Jeroen T. Vermeulen wrote:
That about covers the important stuff. Some more for the "other" bucket
(although they all came repeatedly):
- so how do I pronounce "Postgre"?
...
On the "Postgre" point, I remarked to some friendly people (who are
developing a content management system based on postgr
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I haven't looked at JDBC, but at least in the libpq code, what we could
>> safely do is extend the existing no transaction/in transaction/in failed
>> transaction field to provide a five-way distinction: those three cases
>> plus in sub
Tom Lane wrote:
I don't like using ParameterStatus because it's not designed for dealing
with values that may change many times in a single query. Also it sends
strings, which this really isn't.
What about including the new nesting level in the
SUBBEGIN/SUBCOMMIT/SUBABORT CommandStatus string? Ye
Jeroen T. Vermeulen wrote:
Maybe. OTOH I find it simply disturbing (as a matter of aesthetics, you
could say) that the application can be messing around with the protocol
underneath the middleware it's supposed to live on top of--the middleware
that should expect to be in control of the backend be
I have returned from Germany and Armenia. I will post a summary of my
trip soon. I am going to take tomorrow off and start catching up on
email starting Monday. I estimate it will take me 3-5 days to catch up.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTEC
Kind people,
So far, I have found two places where one can find the SQLSTATE error
codes: a header file, and the errcodes-appendix doc. Those are
excellent places.
Did I miss how to get a list of them in SQL? If I missed it because
it isn't there, what would be a good way to have a current list
On Sat, 3 Jul 2004, Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > - what about Oracle portability.
>
> > IMHO we should rethink if we could make those people happy. How about a
> > loadable personality (IIRC SAPDB has something like that), to exchange
> > the parser in use with a
On Sat, 03 Jul 2004 17:40:23 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Why does START have a different Node from BEGIN anyway? This seems to
> > be a leftover from when people thought they should behave differently.
> > They are the same now, so th
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Why does START have a different Node from BEGIN anyway? This seems to
> be a leftover from when people thought they should behave differently.
> They are the same now, so there's no point in distinguishing them, or is it?
[shrug...] I'd counsel leaving
On Sat, Jul 03, 2004 at 11:03:33AM -0400, Tom Lane wrote:
> Why does postgres.c discriminate against START TRANSACTION where it
> now allows BEGIN? Could simplify code by just allowing all
> TransactionStmt types.
Why does START have a different Node from BEGIN anyway? This seems to
be a leftov
On Sat, Jul 03, 2004 at 02:59:58PM +1200, Oliver Jowett wrote:
>
> I think you mean "between 7.2 and 7.3".
Ah, OK. I thought PREPARE had been added in 7.4. My apologies.
> Yes. I see PREPARE/EXECUTE as a SQL-statement-level, connection-local
> way of getting control over reuse of plans that
On Sat, Jul 03, 2004 at 05:59:17PM +0200, Andreas Pflug wrote:
> classifying the questions we got those three days in the PostgreSQL
> booth on LinuxTag, we had three ever repeating topics, two of them
> non-surprising:
> - what's the difference to MyS***
> - what about win32 native
> - what ab
On Sat, Jul 03, 2004 at 08:20:17AM +0530, Abhijit Menon-Sen wrote:
> But for what it's worth, I strongly dislike the later proposal of making
> prepared statements anonymous, and pattern matching the statement text,
> especially if they reintroduce the need to quote query parameters.
Only in cas
Andreas Pflug <[EMAIL PROTECTED]> writes:
>> How about an external tool that helps in translating apps to
>> SQL-standard syntax? Oracle does accept the standard syntax after all.
> Nice idea, but
> - sources might not be accessible
> - sources might not be easily readable (esp. if not embedded s
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
- what about Oracle portability.
IMHO we should rethink if we could make those people happy. How about a
loadable personality (IIRC SAPDB has something like that), to exchange
the parser in use with a custom one (by a SET comman
Dennis Bjorklund wrote:
Having two parsers would be a nightmare to maintain.
Probably. It just came to my mind because one visitor mentioned he would
look at the bison stuff to do it himself. I meant to enable him to do so
if he likes (and can) without hacking the core product.
If anything on
Andreas Pflug <[EMAIL PROTECTED]> writes:
> - what about Oracle portability.
> IMHO we should rethink if we could make those people happy. How about a
> loadable personality (IIRC SAPDB has something like that), to exchange
> the parser in use with a custom one (by a SET command)? This way we ha
On Sat, 3 Jul 2004, Tom Lane wrote:
> trigger.c: not at all sure about the model for handling trigger firing
> status. It looks like a subtrans could fire triggers that were pending
> from an outer xact, which is dubious at best.
Well, SET CONSTRAINTS potentially needs to check the state of any
On Sat, 3 Jul 2004, Andreas Pflug wrote:
> IMHO we should rethink if we could make those people happy. How about a
> loadable personality (IIRC SAPDB has something like that), to exchange
> the parser in use with a custom one (by a SET command)?
Having two parsers would be a nightmare to mainta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I am searching for a way to have the minimum date and maximum
> date for dates seperated by one week whitout gaps between them.
This is not something you can accomplish (easily) with just SQL,
so you will need some sort of higher language. Here's
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Sat, Jul 03, 2004 at 11:03:33AM -0400, Tom Lane wrote:
>> What about reporting transaction state/nesting level to client? I did not
>> like the GUC-variable approach in the original patch, partly on grounds of
>> efficiency and partly because I doubt
On Sat, Jul 03, 2004 at 11:03:33AM -0400, Tom Lane wrote:
> Here's the promised list of things I think we still need to fix to
> complete the nested-transactions project. I assume you have a private
> todo list as well --- can we compare notes?
Hmm ... there are a lot of things in your list not i
Dear developers,
classifying the questions we got those three days in the PostgreSQL
booth on LinuxTag, we had three ever repeating topics, two of them
non-surprising:
- what's the difference to MyS***
- what about win32 native
- what about Oracle portability.
The third question was asked from s
Greg Stark <[EMAIL PROTECTED]> writes:
> This seems like a irregularity in the API that makes sense only from an
> implementation point of view.
You are attacking a straw man. This does *not* "make sense from an
implementation point of view" --- it's easier to have just one command
(and in fact t
Simon Riggs <[EMAIL PROTECTED]> writes:
> The one question that gets asked the most on these lists AFAICS is:
> **can you tell me what version you're running?**
Mainly because people don't bother to say.
> Would anybody object to adding an extra line at startup that shows the
> version number of
Here's the promised list of things I think we still need to fix to
complete the nested-transactions project. I assume you have a private
todo list as well --- can we compare notes?
Cursors have a whole range of issues, as is already under discussion.
Present design for bufmgr and indexscan clean
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Yeah. Another answer would be to reset the executor state if the cursor
> is modified in a subtransaction that aborts:
Reset is no solution --- rewinding the cursor to the beginning still
leaves it in a state that is inconsistent with the restored stat
"Najib Abi Fadel" <[EMAIL PROTECTED]> writes:
> Any ideas??
> Could this be done with aggregates ??
I think you're going to have to write code that reads all the records, keeps
state representing the current period start and the last seen end date and
outputs data every time it sees a gap like y
> Would anybody object to adding an extra line at startup that shows the
> version number of the database system?
>
> Message suggestion:
> Starting PostgreSQL database system
>
> (Nothing cheesy, just informative and neutrally welcoming...)
>
> Comments?
>
> Best Regards, Simon Riggs
If you
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> If we change the syntax, say by using SUBCOMMIT/SUBABORT for
> subtransactions, then using a simple ABORT would abort the whole
> transaction tree.
This seems like a non-starter to me. That would make it impossible to write
SQL generic code that could
On Sat, Jul 03, 2004 at 18:02:01 +0800,
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> >>Why are they useful If you want PG specific stuff then use the PG
> >>specific catalogs!!!
> >
> >The information schema could be used to provide a more stable interface.
> >The pg catalog changes
Glad to see this is being handled by someone. Other things
of the top of my head:
Add support for psql to display the information.
For that he needs to update pg_get_triggerdef() in
src/backend/utils/adt/ruleutils.c He should probably also check pg_dump
support for them.
Add support
for tab-c
I didn't write that (or at least, I didn't mean to write that :-). The
SQL standard tells that they will not use trailing underscores,
therefore *my* conclusion is that it is future proof (from a standards
perspective) if all PostgreSQL extensions use a trailing underscore.
Which also gives an indi
The one question that gets asked the most on these lists AFAICS is:
**can you tell me what version you're running?**
...and we just had a case of confusing the version itself (which seems
to be a reasonably easy mistake to make).
This information is not displayed at startup, even at debug5. This
Why are they useful If you want PG specific stuff then use the PG
specific catalogs!!!
The information schema could be used to provide a more stable interface.
The pg catalog changes from release to release and it would be nice to
be able to write code which is more future proof.
Really? It wi
Alvaro Herrera wrote:
>On Fri, Jul 02, 2004 at 07:43:47PM -0400, Tom Lane wrote:
>
>
>>Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>
>>
>>>You can't have subtransactions inside an implicit transaction block,
>>>
>>>
>>It would be folly to design on that assumption. We *will* have that
Matthew T. O'Connor wrote:
What about features that have been submitting patches and trying to
get included for a few weeks now.
Specificially, I'm concerned with pg_autovacuum backend integration.
I know people have been busy frying bigger fish, so the patch probably
hasn't recieved much revi
40 matches
Mail list logo
