> > Let me jump in for half a second here (no pun intended), but what
> > about the use of back quotes? ` `? Use a very limited escaping
> > policy of \` => ` and \\ => \ .
>
> Actually, having to double backslashes is one of the things I want
> to get rid of. The here-document-based ideas seem
-On [20030911 15:43], Tom Lane ([EMAIL PROTECTED]) wrote:
>We can't ALTER a table that's already in use when the first ALTER
>starts, either --- its attempt to exclusive-lock the table will fail.
>But once you get the exclusive lock, you can (in Postgres) perform
>a series
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Let me jump in for half a second here (no pun intended), but what
> about the use of back quotes? ` `? Use a very limited escaping policy
> of \` => ` and \\ => \ .
Actually, having to double backslashes is one of the things I want to
get rid of. The
> >> The $$FOO proposal I put forward earlier was consciously modeled on
> >> here-documents.
>
> > Couldn't we allow << at the beginning of the line to mean 'here' document?
>
> No; you could easily be breaking existing queries, for example
Let me jump in for half a second here (no pun intended
Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
> > =20
> > care).
>
> Unfixably? Or just a small oversight?
Updated patch now works on Unixware.
--
Bruce Momjian| http://ca
Subject says it all... if you've got something to get done, now's the
time...
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Marc G. Fournier wrote:
> > > >From what I understand, "not working properly" means slow, not broken, no?
> > > Which means ppl could submit a problem report and it could be fixed for
> > > v7.4.1 ... its not so much 'not working properly' as it is 'not optimal
> > > performance' ...
> >
> > Right
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> Right, though I am not sure people will know _slow_ configuration vs.
>> PostgreSQL is slow.
> No, but definitely something for those discussion performance to add
> to their checklist :)
> BTW, post-compile, running system ... how do you check th
On Fri, 12 Sep 2003, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> >
> >
> > On Thu, 11 Sep 2003, Bruce Momjian wrote:
> >
> > > Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
> > > I guess we could splatter a test for Itanium and Opterion in every port
> > > that co
Marc G. Fournier wrote:
>
> On Thu, 11 Sep 2003, Bruce Momjian wrote:
>
> > I just learned from Larry that Unixware defines intel as i386, not
> > __i386 or __i386__, at least of the native SCO compiler that he uses.
>
> could we put something in the various port files to standardize this? ie.
On Thu, 11 Sep 2003, Bruce Momjian wrote:
> I just learned from Larry that Unixware defines intel as i386, not
> __i386 or __i386__, at least of the native SCO compiler that he uses.
could we put something in the various port files to standardize this? ie.
in unixware.h, add somethinglike:
#if
Marc G. Fournier wrote:
>
>
> On Thu, 11 Sep 2003, Bruce Momjian wrote:
>
> > Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
> > I guess we could splatter a test for Itanium and Opterion in every port
> > that could possibly use it, but then again, if we fall back to no
--On Friday, September 12, 2003 00:06:49 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
I've already sent a whine-a-gram to the compiler guys at SCO.
Prolly you thought of this already, but: getting them to *add*
an implicit #define of __i386__ should be pl
On Thu, 11 Sep 2003, Bruce Momjian wrote:
> Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
> I guess we could splatter a test for Itanium and Opterion in every port
> that could possibly use it, but then again, if we fall back to not
> finding it for some reason, we don
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I've already sent a whine-a-gram to the compiler guys at SCO.
Prolly you thought of this already, but: getting them to *add*
an implicit #define of __i386__ should be plenty easy compared
to getting them to *remove* the one for i386. And while I think
--On Friday, September 12, 2003 00:00:43 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
Please, only the first two. Make the Unixware template add __i386__.
Don't add assumptions about valid user-namespace symbols.
that's reasonable. At least until 64-bi
Larry Rosenman <[EMAIL PROTECTED]> writes:
>> Please, only the first two. Make the Unixware template add __i386__.
>> Don't add assumptions about valid user-namespace symbols.
> that's reasonable. At least until 64-bit UnixWare. :-)
Even then, I'd prefer to put the necessary kluge into template
--On Thursday, September 11, 2003 23:42:53 -0400 Tom Lane
<[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Looking at the code, I wonder if we already have folks not using
spinlocks, and not even knowing it. I don't think problem reports will
be limited to new platforms.
Ve
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Looking at the code, I wonder if we already have folks not using
> > spinlocks, and not even knowing it. I don't think problem reports will
> > be limited to new platforms.
>
> Very likely --- I heard from someone recently who was tr
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Looking at the code, I wonder if we already have folks not using
> spinlocks, and not even knowing it. I don't think problem reports will
> be limited to new platforms.
Very likely --- I heard from someone recently who was trying to run
HPUX/Itanium. A
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, we could do just the configure warning, then plaster tests into the
> > port files to try to hit all the opteron/itanium cases. I am a little
> > concerned that this might throw up a bunch of problem cases that we will
> > patchi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, we could do just the configure warning, then plaster tests into the
> port files to try to hit all the opteron/itanium cases. I am a little
> concerned that this might throw up a bunch of problem cases that we will
> patching for a while.
Probably
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I guess we could splatter a test for Itanium and Opterion in every port
> > that could possibly use it, but then again, if we fall back to not
> > finding it for some reason, we don't get a report because we silently
> > fall back to s
--On Thursday, September 11, 2003 23:13:54 -0400 Tom Lane
<[EMAIL PROTECTED]> wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
Bruce sent me a copy of the patch, and it BREAKS UnixWare (If
y'all= =20
care).
Unfixably? Or just a small oversight?
I'm actually not worried about platform
Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
> > =20
> > care).
>
> Unfixably? Or just a small oversight?
>
> I'm actually not worried about platforms that are actively being tested.
> It's the stuff
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
> =20
> care).
Unfixably? Or just a small oversight?
I'm actually not worried about platforms that are actively being tested.
It's the stuff that hasn't been confirmed recent
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I guess we could splatter a test for Itanium and Opterion in every port
> that could possibly use it, but then again, if we fall back to not
> finding it for some reason, we don't get a report because we silently
> fall back to semaphores. That's what ha
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Thu, 11 Sep 2003, Tom Lane wrote:
>> Well, as long as you're prepared to reduce the list of known supported
>> platforms to zero as of 7.4beta3, and issue a fresh call for port reports.
> I didn't think we had done that yet ... had we? called fo
On Thu, 11 Sep 2003, Bruce Momjian wrote:
> Yes, but to throw an error if spinlocks aren't found, we need this
> patch. We would have to test for Opteron in all the platforms that test
> for specific CPU's but don't test for opteron, and might support
> opterion/itanium, but even then, we don't
--On Thursday, September 11, 2003 23:46:56 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Thu, 11 Sep 2003, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The problem with waiting for 7.5 is that we will have no error
> reporting when our non-spinlock code is being execu
Marc G. Fournier wrote:
> > But it seems to me that this is mostly a cosmetic cleanup and therefore
> > not the kind of thing to be doing late in beta. Couldn't we do
> > something that affects only Opteron/Itanium and doesn't take a chance
> > on breaking everything else?
>
> I just went through
On Thu, 11 Sep 2003, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem with waiting for 7.5 is that we will have no error reporting
> > when our non-spinlock code is being executed, and with Opteron/Itanium,
> > it seems like a good time to get it working.
>
> Well, as
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem with waiting for 7.5 is that we will have no error reporting
> > when our non-spinlock code is being executed, and with Opteron/Itanium,
> > it seems like a good time to get it working.
>
> Well, as long as you're prepared
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The problem with waiting for 7.5 is that we will have no error reporting
> when our non-spinlock code is being executed, and with Opteron/Itanium,
> it seems like a good time to get it working.
Well, as long as you're prepared to reduce the list of known
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Prompted by confusion over Itanium/Opterion, I have written a patch to
> > improve the way we define spinlocks for platforms and cpu's.
>
> The main.c part of the patch strikes me as irrelevant to the claimed
> purpose and unlikely to
This is the email describing the changes in the patch for 7.4.
---
Bruce Momjian wrote:
> Prompted by confusion over Itanium/Opterion, I have written a patch to
> improve the way we define spinlocks for platforms and cpu's.
Tom Lane wrote:
> Keep in mind that we have two different requirements: the quote start
> marker has to be recognizable while we are parsing SQL (or possibly
> plpgsql) code. The quote end marker has to be recognizable while we are
> scanning text that could be almost anything.
>
> The cute thing
Sean Chittenden wrote:
> > Backend only forks(). I think you would be better off using
> > Makefile macros to _remove_ those two libraries.
> >
> > I see this:
> >
> > $(filter crypt.o getaddrinfo.o inet_aton.o snprintf.o strerror.o path.o
> > thread.o, $(LIBOBJS))
> >
> > Seems you need
Below is the email that prompted me to add the derived files to
WIN32_DEV CVS.
However, most people don't want them in there, so I have removed them,
and updated the web page to recommend the nightly snapshots (which have
the derived files), and mentioned the tools that will be needed for a
CVS b
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... You are saying it is safer to
> make it at the beginnning of a line _and_ have it be something that
> isn't used in SQL, but $$ is used in Perl, so I don't see the big
> advantage either way --- once you say X has to begin at the beginning of
> the li
On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> of shared tables in the first place. The trouble with doing so is that
> if you only vacuum pg_shadow through template1, then only template1 will
> ever have up-to-date statistic
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
So you are requiring the identical text to appear at the beginning and
end of the quote, rather than a here document that would be:
<
...
END
or in your example:
$$END
...
END
Yes, I was thinking of r
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> On Thu, 2003-09-11 at 17:11, Tom Lane wrote:
>> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
>>> I designed it that way. It was my understanding that all of the system
>>> tables pg_class etc... are shared tables, available in all databases,
Tilo Schwarz <[EMAIL PROTECTED]> writes:
> What about the Python approach: The literal text is enclosed either in a pair
> of three single quotes or three double quotes.
That might be okay if we were working in a vacuum, but we aren't. Among
other things, the SQL spec tells us what 'quote''' ...
On Thu, 2003-09-11 at 17:11, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > I designed it that way. It was my understanding that all of the system
> > tables pg_class etc... are shared tables, available in all databases,
> > but actually stored as only one central set of r
On Thu, 11 Sep 2003, Tom Lane wrote:
> It is possible that we could allow the start marker to be not at the
> beginning of its line, which would create structures very very close
> to shell here-documents:
>
> CREATE FUNCTION foo() RETURNS int AS $$FUNCTION
> ... text here ...
>
Bruce Momjian writes:
> Tom Lane wrote:
> > Jon Jensen <[EMAIL PROTECTED]> writes:
> > > Is there a reason not to use here documents?
> >
> > The $$FOO proposal I put forward earlier was consciously modeled on
> > here-documents. We cannot use exactly the shell syntax for
> > here-documents, thoug
Jon Jensen wrote:
> On Thu, 11 Sep 2003, Bruce Momjian wrote:
>
> > > I would definitely like to see us adopt a proposal that is like
> > > here-documents to the extent that there's a family of possible
> > > terminator markers and not only one. But we'll have to adjust the
> > > syntax a little
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So you are requiring the identical text to appear at the beginning and
> end of the quote, rather than a here document that would be:
> < ...
> END
> or in your example:
> $$END
> ...
> END
Yes, I was thinking of re
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, that is true. I didn't like the beginning-of-line requirement for
> here documents for that reason. However, we are already requiring the
> thing to be at the beginning of the line. You are saying it is safer to
> make it at the beginnning of a li
On Thu, 11 Sep 2003, Bruce Momjian wrote:
> > I would definitely like to see us adopt a proposal that is like
> > here-documents to the extent that there's a family of possible
> > terminator markers and not only one. But we'll have to adjust the
> > syntax a little bit. If you don't like $$FOO,
[EMAIL PROTECTED] ("Matthew T. O'Connor") writes:
> On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
>> Something I am feeling a little suspicious of is that I haven't seen,
>> in the logs, pg_autovacuum looking at pg_ tables.
>>
>> I know that if we don't periodically vacuum such system t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The $$FOO proposal I put forward earlier was consciously modeled on
> >> here-documents.
>
> > Couldn't we allow << at the beginning of the line to mean 'here' document?
>
> No; you could easily be breaking exist
Jan Wieck wrote:
> >> The beauty of here-documents is that you specify your closing tag on a
> >> per usage base and can vary that depending on the content you need to
> >> enclose. Keep in mind that this literal mechanism is not only used for
> >> PL/pgSQL, but for other languages like PL/Tcl a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The $$FOO proposal I put forward earlier was consciously modeled on
>> here-documents.
> Couldn't we allow << at the beginning of the line to mean 'here' document?
No; you could easily be breaking existing queries, for example
regres
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> Sounds good. I just think keywords in general are weird to use for
> quoting. We use "'" for quoting, so something similar like another
> operator combination would be nice. I have never been fond of the
> here-document approach, t
Tom Lane wrote:
> Jon Jensen <[EMAIL PROTECTED]> writes:
> > Is there a reason not to use here documents?
>
> The $$FOO proposal I put forward earlier was consciously modeled on
> here-documents. We cannot use exactly the shell syntax for
> here-documents, though, mainly because we already have m
Jan Wieck wrote:
>
>
> Bruce Momjian wrote:
>
> > Sounds good. I just think keywords in general are weird to use for
> > quoting. We use "'" for quoting, so something similar like another
> > operator combination would be nice. I have never been fond of the
> > here-document approach, though
Andreas Pflug wrote:
> solution would be a great enhancement, details are now merely a question
> of taste.
>
> While this sounds "nearly done" for me, as there seems some fundamental
> consense, I'll will probably have to wait for 7.5?
Yes, has to wait for 7.5.
--
Bruce Momjian
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
>> [Rummaging around...] These tables are being added for template1, but
>> apparently not for "main" databases. That looks like a bit of a fly
>> in the ointment...
> I designed it that wa
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand alone on a line.
Hard to detect whitespace might trip things up. I wish
Bruce Momjian wrote:
Sounds good. I just think keywords in general are weird to use for
quoting. We use "'" for quoting, so something similar like another
operator combination would be nice. I have never been fond of the
here-document approach, though I can see the value of doing
here-documen
Matthew T. O'Connor wrote:
> On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
> > Something I am feeling a little suspicious of is that I haven't seen,
> > in the logs, pg_autovacuum looking at pg_ tables.
> >
> > I know that if we don't periodically vacuum such system tables as
> > pg_cla
Jon Jensen <[EMAIL PROTECTED]> writes:
> Is there a reason not to use here documents?
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents. We cannot use exactly the shell syntax for
here-documents, though, mainly because we already have meaning assigned
to strings l
On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
> Something I am feeling a little suspicious of is that I haven't seen,
> in the logs, pg_autovacuum looking at pg_ tables.
>
> I know that if we don't periodically vacuum such system tables as
> pg_class, pg_attribute, pg_statistic, and pg_
On Thu, 2003-09-11 at 15:02, Bruce Momjian wrote:
> Patch applied. You might want to look at pg_dump/dumputils.c::fmtId()
> for a function that does smart quoting.
OK, thanks.
---(end of broadcast)---
TIP 8: explain analyze is your friend
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I believe we could make
>> it a good deal more robust if both the opening and closing markers
>> (whatever they are) are required to stand alone on a line.
>>
> Hard to detect whitespace might trip things up. I wish I had a $ for
>
Tom Lane wrote:
I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand alone on a line.
Hard to detect whitespace might trip things up. I wish I had a $ for
every time that has made my life difficult.
cheers
andrew
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, it sure sounds like a bug. What logic is there that table access
> use the view permissions, but not function access? Could we just use
> SECURITY DEFINER for function calls in views?
You're confusing two distinct questions, I think. One is how
On Thu, 11 Sep 2003, Tom Lane wrote:
> People seem to be assuming that this feature needs to be impervious to
> whitespace and being adjacent to other things. I believe we could make
> it a good deal more robust if both the opening and closing markers
> (whatever they are) are required to stand a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Something that includes "'" would be clearest. I thought of <' and '>,
> but this would break:
> if var <'yes'
People seem to be assuming that this feature needs to be impervious to
whitespace and being adjacent to other things. I believe we could
Bruce Momjian wrote:
Something that includes "'" would be clearest. I thought of <' and '>,
but this would break:
I'm not sure that using a quote is necessarily clearest. But it's a
matter of taste. I had thought of {{ and }} as maybe working.
[snip]
One clean way would be to use {' to start
Patch applied. You might want to look at pg_dump/dumputils.c::fmtId()
for a function that does smart quoting.
---
Matthew T. O'Connor wrote:
> On Wed, 2003-09-10 at 15:57, Bruce Momjian wrote:
> > I assume the attached patc
Andreas Pflug wrote:
> Sergio A. Kessler wrote:
>
>
> >
> > Too sad, all special chars are used up for operators
>
>
> also '{' '}' are used ?
>
> I've only seen this in ACLs, so it might be usable. Tom, Bruce?
Something that includes "'" would be clearest. I thought of <' and '>,
but th
Sergio A. Kessler wrote:
Too sad, all special chars are used up for operators
also '{' '}' are used ?
I've only seen this in ACLs, so it might be usable. Tom, Bruce?
Regards,
Andreas
---(end of broadcast)---
TIP 6: Have you searched our list
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >You mean if the special quotes are <-- and -->, <-> would be the
> >same as '-'?
> >
> >
>
> If they work as the standard ' quote (and that seems to be Toms
> intention), obviously.
>
> Besides, we have to care specially about -->. Remember
Darko Prenosil writes:
> Here is the idea: there is problem to find out in which encoding is using mo
> file, but we can force gettext to serve known encoding for example utf8.
> After that we can always convert from unicode to client encoding.
Hmm, I've never heard of bind_textdomain_codeset().
Bruce Momjian wrote:
You mean if the special quotes are <-- and -->, <-> would be the
same as '-'?
If they work as the standard ' quote (and that seems to be Toms
intention), obviously.
Besides, we have to care specially about -->. Remember the complaints about
select 1--1,
behaving diffe
At 12:03 AM 9/11/03 -0400, Matthew T. O'Connor wrote:
Adam, can you please give this a test as you are the person who caught
the bug in the first place.
Thanks,
Matthew T. O'Connor
I applied your patch and it works fine for me.
--- Adam Kavan
---(end of broadcast)---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Someone asked me a question about view and function permissions. I
> > assumed all object access done by a view would be based on the
> > permissions on the view, and not the permissions of the objects.
>
> Table references are check
Andreas Pflug wrote:
> >My objection to the proposal FUNCTIONBODY is that it makes it look like
> >the feature is only useful in CREATE FUNCTION. In point of fact, the
> >quoting facility could be used to construct any SQL string literal. The
> >comparison points I am thinking about are shell her
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Uh, the problem with long keywords is that you are then requiring the
_parser_ to identify those keywords, and at that point, the entire text
between the keywords has been sliced up by the lexer, which will
certainly make it a mess. I m
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Someone asked me a question about view and function permissions. I
> assumed all object access done by a view would be based on the
> permissions on the view, and not the permissions of the objects.
Table references are checked according to the owner of
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Uh, the problem with long keywords is that you are then requiring the
> > _parser_ to identify those keywords, and at that point, the entire text
> > between the keywords has been sliced up by the lexer, which will
> > certainly make i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Uh, the problem with long keywords is that you are then requiring the
> _parser_ to identify those keywords, and at that point, the entire text
> between the keywords has been sliced up by the lexer, which will
> certainly make it a mess. I might be wron
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >Tom Lane wrote:
> >
> >
> >>The discussion so far today seems to be entirely a rehash of arguments
> >>already made (and in many cases already rebutted). Rather than wasting
> >>list bandwidth with this, I think each camp ought to go off and do t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Another idea would be to enable another set of quoting characters, like:
Yeah, I was toying with that also; it would be nearly the same as the
psql literal proposal, but pushed into the backend. I am not sure what
the quoting symbols should look like th
Bruce Momjian wrote:
Tom Lane wrote:
The discussion so far today seems to be entirely a rehash of arguments
already made (and in many cases already rebutted). Rather than wasting
list bandwidth with this, I think each camp ought to go off and do their
homework. Give us *details* of how your s
On Thursday 11 September 2003 18:08, Darko Prenosil wrote:
> On Thursday 11 September 2003 18:00, Zeugswetter Andreas SB SD wrote:
> > > > I'm confused. Right on the MinGW download page is a link for
> > > > bison-1.875.
> > >
> > > Yep, but I had problems with it. Author confirmed that there coul
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Some people think a "sql syntax solution" is needed, and some do not.
> >>
> > So does this get resolved by a vote?
>
> A vote is a little premature when we don't have fully-developed
> alternatives to choose fr
On Thursday 11 September 2003 18:00, Zeugswetter Andreas SB SD wrote:
> > > I'm confused. Right on the MinGW download page is a link for
> > > bison-1.875.
> >
> > Yep, but I had problems with it. Author confirmed that there could be
> > some problems creating processes (for example M4). However i
> > I'm confused. Right on the MinGW download page is a link for bison-1.875.
> >
> >
> Yep, but I had problems with it. Author confirmed that there could be some
> problems creating processes (for example M4). However if You make it work,
> I'll be interested to know how. Check the MinGW maili
Jon Jensen <[EMAIL PROTECTED]> writes:
> On Thu, 10 Sep 2003, Doug McNaught wrote:
>
> > But Perl/DBI does escaping for you, so all you'd have to do is:
Only because the FE protocol is new and the DBD driver hasn't switched to
using it.
> > $sth = $dbh->prepare
> >("CREATE FUNCTION foo(x te
Someone asked me a question about view and function permissions. I
assumed all object access done by a view would be based on the
permissions on the view, and not the permissions of the objects.
While table access done in a view follows this outline, function call
access does not. In my tests be
On Thursday 11 September 2003 17:30, Matthew T. O'Connor wrote:
> On Wed, 2003-09-10 at 12:03, Bruce Momjian wrote:
> > Because MinGW/Msys doesn't come with flex/bison by default, I have added
> > those derived files to the WIN32_DEV branch in CVS.
>
> I'm confused. Right on the MinGW download pag
On Wed, 2003-09-10 at 12:03, Bruce Momjian wrote:
> Because MinGW/Msys doesn't come with flex/bison by default, I have added
> those derived files to the WIN32_DEV branch in CVS.
I'm confused. Right on the MinGW download page is a link for
bison-1.875.
---(end of broad
On Thursday 11 September 2003 10:40, Andreas Pflug wrote:
> Richard Huxton wrote:
> >On Thursday 11 September 2003 09:33, Andreas Pflug wrote:
> >>*NO PARSING*
> >>The script must be stuffable into PQexec in total, backend does the rest.
> >>
> >>Again: not psql, but sql language itself must provid
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Some people think a "sql syntax solution" is needed, and some do not.
>>
> So does this get resolved by a vote?
A vote is a little premature when we don't have fully-developed
alternatives to choose from. The psql "literal" proposal
Bruce Momjian wrote:
Because MinGW/Msys doesn't come with flex/bison by default, I have added
those derived files to the WIN32_DEV branch in CVS. It makes it easier
for people to install _just_ MinGW and compile PostgreSQL on Win32. The
branch will live for only 1-2 months until we start 7.5 dev
Jeroen Ruigrok/asmodai <[EMAIL PROTECTED]> writes:
> -On [20030909 00:42], Tom Lane ([EMAIL PROTECTED]) wrote:
>> IIRC, Oracle does not have rollback-able DDL. That might imply that the
>> reason they have MODIFY CONSTRAINT is that in Oracle you can't use the
>> above way to eliminate the window.
1 - 100 of 107 matches
Mail list logo
