Claudio Natoli wrote:
> For application to HEAD, following community review.
>
> Supplement to previous win32 patch for dfmgr. Win32 replacement for
> configure time constants like PKGLIBDIR.
+ /*
+ * Determine the directory of installed files, on the assumption that
+ * win32 will have a common
Peter Eisentraut said:
> Claudio Natoli wrote:
>> For application to HEAD, following community review.
>>
>> Supplement to previous win32 patch for dfmgr. Win32 replacement for
>> configure time constants like PKGLIBDIR.
>
> + /*
> + * Determine the directory of installed files, on the assumption
Dear Patchers,
Please find attached a patch which allows "LIKE/ILIKE/NOT LIKE/NOT ILIKE"
as operators for ANY/SOME/ALL constructs.
SELECT 'foo' LIKE ANY (ARRAY['%a','%o']);
It should also fix some other places where a "~~" operator was allowed,
but not the LIKE operator in the very same place.
Thanks. I was getting to that, but hadn't started :-)
Per our discussion off-list, I agree with this method, and the patch
looks fine to me.
//Magnus
> -Original Message-
> From: Claudio Natoli [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 25, 2004 2:07 AM
> To: '[EMAIL PROTECTED]'
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Please find attached a patch which allows "LIKE/ILIKE/NOT LIKE/NOT ILIKE"
> as operators for ANY/SOME/ALL constructs.
This seems to allow a whole lot of unintended and probably uncool things
as well. "ORDER BY NOT LIKE", for instance.
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Supplement to previous win32 patch for dfmgr. Win32 replacement for
> configure time constants like PKGLIBDIR.
This is exactly the sort of cruft I was hoping we would not get saddled
with by a Windows port.
If the problem is that we need PKGLIBDIR not
Claudio Natoli <[EMAIL PROTECTED]> writes:
> + #ifdef WIN32
> + /* Interrupted by socket/APC interaction? */
> + if (n < 0 && GetLastError() == ERROR_IO_PENDING)
> + errno = EINTR;
> + #endif
This seems a bit schizophrenic; if you can assign to errno, why can't you
read from it
Tom Lane wrote:
Claudio Natoli <[EMAIL PROTECTED]> writes:
Supplement to previous win32 patch for dfmgr. Win32 replacement for
configure time constants like PKGLIBDIR.
This is exactly the sort of cruft I was hoping we would not get saddled
with by a Windows port.
If the problem is that we
>Claudio Natoli <[EMAIL PROTECTED]> writes:
>> + #ifdef WIN32
>> +/* Interrupted by socket/APC interaction? */
>> +if (n < 0 && GetLastError() == ERROR_IO_PENDING)
>> +errno = EINTR;
>> + #endif
>
>This seems a bit schizophrenic; if you can assign to errno,
>why can't you
>read
Andrew Dunstan wrote:
> >Every "#ifdef WIN32" I see reduces my opinion of the quality of work
> >being done for this port.
> >
> >
> >
>
> Tom,
>
> I think in defense of Claudio and company, it should be noted that there
> has been a desire not to disturb existing functionality more than
>
> Would look more consistent if the code looked like
>
> if (n < 0 && errno == ERROR_IO_PENDING)
> errno = EINTR;
It would be more consistent, but unfortunately GetLastError() != errno.
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the f
Tom Lane wrote:
> If the problem is that we need PKGLIBDIR not to be frozen at compile
> time, then let's fix the problem for everybody, not add a pile of
> undocumented #ifdef WIN32 hacks. (And it is a problem for everybody;
Happy to go with whatever you can suggest. However, will point out tha
Claudio Natoli <[EMAIL PROTECTED]> writes:
> It would be more consistent, but unfortunately GetLastError() != errno.
Yeah, I saw Magnus' explanation. So essentially this is a workaround
for a bug in Windows' select() emulation.
Rather than hoping that we'll remember to decorate every select() ca
> Rather than hoping that we'll remember to decorate every select() call
> with this workaround, would it make sense to use a wrapper function?
> I'm loath to invent pg_select() but it might be cleaner than this.
We'd also need pg_recv() and pg_send(). Chances are it can happen with every
blockin
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Every "#ifdef WIN32" I see reduces my opinion of the quality of work
>> being done for this port.
> At risk of getting (further? :-) on your bad side, IMHO that is a specious
> metric.
Well, it's surely not the only interesting metri
Claudio Natoli <[EMAIL PROTECTED]> writes:
>> I'm loath to invent pg_select() but it might be cleaner than this.
> We'd also need pg_recv() and pg_send(). Chances are it can happen with every
> blocking socket call :-(
Ugh. Is there a way we can insert a wrapper layer without modifying the
call
> Ugh. Is there a way we can insert a wrapper layer without modifying the
> call sites? I'm thinking of some kind of macro hack, say
> [snip]
Sure. Think we've even done this before (also, prevents developers needing
to remember to use pg_*).
The reason I think it was avoided for select(), in
Tom Lane said:
>
> I'm not expecting to see zero ifdefs --- certainly not in the port
> modules ;-). But Bruce's search, further up in the thread, showed that
> #ifdef WIN32's are sneaking into a lot of modules that probably
> shouldn't have any platform dependencies. I don't think that's a good
On Thu, Mar 25, 2004 at 07:57:19PM -0500, Tom Lane wrote:
> I'm not expecting to see zero ifdefs --- certainly not in the port
> modules ;-). But Bruce's search, further up in the thread, showed that
> #ifdef WIN32's are sneaking into a lot of modules that probably
> shouldn't have any platform d
I've applied the attached patch to CVS HEAD. It makes a few more SQL
statement references into cross-references and makes some other minor
improvements to the documentation.
-Neil
more_xref_work-3.patch
Description: Binary data
---(end of broadcast)
> I'm not expecting to see zero ifdefs --- certainly not in the port
> modules ;-). But Bruce's search, further up in the thread, showed that
> #ifdef WIN32's are sneaking into a lot of modules that probably
> shouldn't have any platform dependencies.
For the most part, I disagree (in fact, I
> Fabien COELHO <[EMAIL PROTECTED]> writes:
> > Please find attached a patch which allows "LIKE/ILIKE/NOT LIKE/NOT ILIKE"
> > as operators for ANY/SOME/ALL constructs.
>
> This seems to allow a whole lot of unintended and probably uncool things
> as well. "ORDER BY NOT LIKE", for instance.
Yes.
22 matches
Mail list logo