Tom Lane wrote:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> > I've just found the stumbling block: the -c option of psql wraps all in
> > a transaction, as man psql says:
> > ...
> > Thank you for clarification, I wouldn't have expected that (especially
> > because CREATE DATABASE itself
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We aren't going to disable that --- we are considering disabling the
> backend from treating it as a single transaction.
Or even more specifically, making sure that that only happens if you
explicitly put begin/commit into the -c string.
One thing I thi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we need a TODO for this?
Well, if we *don't* change the backend to disallow multi statements per
PQexec, then we'd probably better do something about this. If we do
make that change then it's not a problem anymore.
>> Hm, that's an interesting point
elein wrote:
> On Fri, Jan 05, 2007 at 08:45:51PM -0500, Tom Lane wrote:
> > Ron Mayer <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >>> What value is allowing multiple queies via PQexec()
> > >>
> > >> The only argument I can think of is th
On Fri, Jan 05, 2007 at 08:45:51PM -0500, Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> What value is allowing multiple queies via PQexec()
> >>
> >> The only argument I can think of is that it allows applications t
Do we need a TODO for this?
---
Tom Lane wrote:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> > I've just found the stumbling block: the -c option of psql wraps all in
> > a transaction, as man psql says:
> > ...
> >
Ron Mayer wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> What value is allowing multiple queies via PQexec()
> >
> > The only argument I can think of is that it allows applications to be
> > sloppy about parsing a SQL script into individual commands before they
> > sen
>> Tom Lane wrote:
>>> Bruce Momjian <[EMAIL PROTECTED]> writes:
What value is allowing multiple queies via PQexec()
>>>
>>> The only argument I can think of is that it allows applications to be
>>> sloppy about parsing a SQL script into individual commands before they
>>> send it. (I think
On Jan 4, 2007, at 11:30 PM, Bruce Momjian wrote:
No, psql isn't the point: we can certainly make its behavior match
the
backend's. What I'm wondering about is the effect on random PG-using
applications: should we forbid them from sending multiple SQL
commands
per PQexec (or equivalent in o
Ron Mayer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> What value is allowing multiple queies via PQexec()
>>
>> The only argument I can think of is that it allows applications to be
>> sloppy about parsing a SQL script into individual commands bef
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> What value is allowing multiple queies via PQexec()
>
> The only argument I can think of is that it allows applications to be
> sloppy about parsing a SQL script into individual commands before they
> send it. (I think initdb may be g
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The only argument I can think of is that it allows applications to be
> >> sloppy about parsing a SQL script into individual commands before they
> >> send it. (I think initdb may be guilty of exactly that BTW...)
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The only argument I can think of is that it allows applications to be
>> sloppy about parsing a SQL script into individual commands before they
>> send it. (I think initdb may be guilty of exactly that BTW...) At the
>> same time you
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What value is allowing multiple queries via PQexec()
>
> The only argument I can think of is that it allows applications to be
> sloppy about parsing a SQL script into individual commands before they
> send it. (I think initdb may be
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What value is allowing multiple queies via PQexec()
The only argument I can think of is that it allows applications to be
sloppy about parsing a SQL script into individual commands before they
send it. (I think initdb may be guilty of exactly that BTW..
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> >>> Is there a good reason to not let psql -c behave exactly like psql from
> >>> STDIN?
> >>
> >> Backwards compatibility, mostly --- there seems to be a conside
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
>>> Is there a good reason to not let psql -c behave exactly like psql from
>>> STDIN?
>>
>> Backwards compatibility, mostly --- there seems to be a considerable
>> risk of subtly breaki
Tom Lane wrote:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Hm, that's an interesting point. psql's -c just shoves its whole
> >> argument string at the backend in one PQexec(), instead of dividing
> >> at semicolons as psql does with normal input.
>
> > Is there a
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, that's an interesting point. psql's -c just shoves its whole
>> argument string at the backend in one PQexec(), instead of dividing
>> at semicolons as psql does with normal input.
> Is there a good reason to not let psql -c
Hi,
Tom Lane wrote:
Hm, that's an interesting point. psql's -c just shoves its whole
argument string at the backend in one PQexec(), instead of dividing
at semicolons as psql does with normal input. And so it winds up as
a single transaction because postgres.c doesn't force a transaction
commi
Am Donnerstag, 4. Januar 2007 16:36 schrieb Tom Lane:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Hm, that's an interesting point. psql's -c just shoves its whole
> argument string at the backend in one PQexec(), instead of dividing
> at semicolons as psql does with normal input. And so i
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> I've just found the stumbling block: the -c option of psql wraps all in
> a transaction, as man psql says:
> ...
> Thank you for clarification, I wouldn't have expected that (especially
> because CREATE DATABASE itself says, it cannot be run insid
Hi,
Tom Lane wrote:
It should happen automatically at commit of the CREATE DATABASE ... and
you'd not be able to see the pg_database row before that anyway. So I'm
not clear on what you're worried about.
I've just found the stumbling block: the -c option of psql wraps all in
a transaction, a
Tom Lane wrote:
It should happen automatically at commit of the CREATE DATABASE ... and
you'd not be able to see the pg_database row before that anyway. So I'm
not clear on what you're worried about.
Okay, thanks. I'll have to investigate on why exactly I still get the
error, then. That's unc
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Most probably I better go another way, than fiddling with postgres
> startup internals. Is there a way to be sure the flatfile has been
> written to disk after a CREATE DATABASE? I would like to ensure I can
> connect to a newly created database.
Hello Tom,
Tom Lane wrote:
In what PG version?
Postgres-R 8.3devel ;-)
Because the postmaster doesn't have direct database access. If it did,
any corruption of shared memory would risk crashing the postmaster
along with the backends.
Understood, thanks.
Most probably I better go another
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> I've just run into a race condition with creating a database and
> connecting to it immediately afterwards. I'm getting a "database %s not
> found" error just after the first flatfiles check in InitPostgres().
In what PG version?
> What that Fin
Hi,
I've just run into a race condition with creating a database and
connecting to it immediately afterwards. I'm getting a "database %s not
found" error just after the first flatfiles check in InitPostgres().
What that FindMyDatabase() there does, besides checking if the database
exists, is
28 matches
Mail list logo
